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ABSTRACT 


Continuous Acquisition and Life-cycle Support (CALS) is an evolving strategy 
designed to take defense information from its current paper-intensive form to a totally 
electronic mode of operation by means of information integration and automation. To 
take full advantage of CALS, it is essential to accommodate distributed CALS computer 
networks, and to enable the interconnection of selected heterogeneous components in the 
networks. However, as CALS telecommunications deals with multi-level security data, it 
is critical to incorporate adequate security plans into the telecommunication plan. 

This thesis analyzes the requirements for a secure telecommunications plan that 
includes telecommunications standards and protocols, data exchange protocols, 
transmission media, and methods of network security necessary to implement CALS in the 
Korea defense environment. Literature reviews and expert interviews are used to support 
findings and conclusions. 

To accomplish a fiilly digitized CALS environment, the author concludes that 
proper data protection standards and methods must be provided and tested as part of the 
overall CALS telecommunications architecture. Enabling technology and a responsive 
management infrastructure must be in place to ensure successful implementation of CALS. 
The decision to select mechanisms should be made based on the comparison between 
security and integrity, in terms of efficiency, effectiveness, and availability. 
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I. INTRODUCTION 


A. OVERVIEW 

The continuous growth of computer and information technologies is rapidly 
changing the way of doing business. Industries face an increased necessity to integrate 
and network for better quality and lower cost products and services or, in other words, for 
"doing more with less." Continuous Acquisition and Life-Cycle Support (CALS) 
promotes an environment where business processes for the design, development, 
manufacturing, distribution, and servicing of products are integrated and streamlined, 
based on a common digital database. 

CALS was begun primarily as a strategy to improve the productivity and quality of 
weapon systems information at lower life-cycle costs by facilitating the integration of 
digital technical information for weapon system acquisition, design, manufacture, and 
support. Today, CALS has become recognized as a leading-edge prototype for the 
"virtual enterprise" in the twenty first century [Ref 1]. 

In order to create an open systems environment, the CALS implementation 
strategy focuses on distributed databases, connected by local area and wide area networks 
that will provide the U.S. Department of Defense (DoD) and industry with direct access to 
information they need. While this evolutionary goal of modernizing information exchange 
will reduce the costs of data handling, and bring more timely and accurate data to users, 
protecting CALS data and its system components make the achievement of this system a 
challenging goal. Thus, appropriate protection of all the CALS data and components 
should be considered a vital part of CALS implementation strategy for the confidentiality 
and integrity of CALS data. 

In the Korean defense environment, a reduced defense budget and the burden of 
paper-intensive data flows require a new way of dealing with information to acquire 
weapon systems and support its life-cycle maintenance at lower costs with better quality. 
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Also, as emerging information technologies (eg.. Concurrent Engineering (CE) and 
Electronic Commerce/Electronic Data Interchange (EC/EDI)) are becoming important 
parts of CALS, the effort to adopt CALS strategy has not only brought about the 
cooperation of Ministry of Defense (MND) and defense industry in Korea, but also 
affected competitive industries who want to pursue enterprise integration and industrial 
networking at a rapidly increasing pace. 

Although CALS envisions highly profitable goals (e g., reduced cost, integrated 
timely information, a paperless work place), those who want to launch this nation-wide 
project with little prior experience should carefully consider the current obstacles 
challenging the CALS implementation objectives. 

B. OBJECTIVES 

When an integrated data environment among various organizations ~ including 
governmental and industrial organizations — is realized via an electronic ally linking the 
dissimilar databases of these organizations, the concern for individual and organizational 
confidentiality is also growing. Therefore, the success of CALS is contingent upon finding 
a reasonable balance between security and effective data sharing [Ref 2]. 

As a part of the effort to find a balance between data integrity and security, this 
thesis will investigate the methods to secure CALS data via telecommunications 
architecture for the CALS implementation. The primary objective of this research is to 
define the secure telecommunications plan for the implementation of CALS in the Korean 
defense environment. To achieve the primary objective, this research assesses: (1) 
required components of CALS telecommunications including standards, data transmission 
requirement, and network infrastructure, (2) necessary protection methods for the 
telecommunication channel and data itself, and (3) appropriate security management for 
the secure telecommunications architecture. 
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C. SCOPE AND ORGANIZATION 


This thesis begins by briefly reviewing the CALS initiative and its strategies. To 
present secure telecommunications architecture required for the CALS implementation, 
the data transmitted via CALS network, the components of CALS network, and the 
protection methods for CALS data will be analyzed. Although CALS security includes 
physical security in a trusted computer system, multi-level secure database management 
systems, and many other issues, this thesis will focus primarily on network issues related 
to CALS telecommunications plan. 

This thesis is organized in six chapters. Chapter II, Continuous Acquisition and 
Life-Cycle Support (CALS), presents the background of CALS and its critical 
components. Chapter III, CALS Telecommunications Plan, analyzes requirements for the 
CALS data transmission. Chapter IV, Network Security and Related Issues, presents 
current protection methodologies related to the CALS network security and data 
protection. Chapter V, Security Management of CALS Telecommunications, overviews 
relative security policies and standards, and then presents a secure telecommunications 
architecture for the CALS implementation in Korea. Finally, Chapter VI, Conclusion, 
presents conclusions drawn from this research and discusses further research 
requirements. 
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II. CONTINUOUS ACQUISITION AND LIFE-CYCLE SUPPORT 

(CALS) 


CALS is defined as a Department of Defense (DoD) and industry strategy to 
enable more effective generation, exchange, management, and use of digital information 
that supports the life cycle of a product through the use of national and international 
standards, business process changes, and advanced technology applications. [Ref 3] In 
this Chapter, the history, strategy, and standards and specifications for CALS are 
presented briefly. Next, the key components to enable the goals of CALS are described. 

A. BACKGROUND 

1. History of CALS 

In September 1985, CALS (which then stood for "Computer-Aided Logistics 
Support") was officially initiated by a memorandum from the U.S. Deputy Secretary of 
Defense to implement the recommendations of a Joint Industry/DoD Task Force in an 
effort to standardize digital encoding of technical information [Ref 4]. At that time, 
several emerging technologies stimulated new thinking about managing and publishing 
logistics technical information. Those new technologies enabled a transition from 
paper-based documents to ones that are created, delivered, used, and maintained in digital 
form. CALS reduces costs by enabling users to buy information that is more accurate, 
current, timely, and entered once and used many times. 

The opportunities offered by CALS technologies spread quickly to encompass 
weapon systems acquisition information. By 1988, CALS expanded to include acquisition 
and stood for "Computer-aided Acquisition and Logistics Support." It could be said that 
CALS was officially launched by a memorandum from Deputy Secretary of Defense dated 
5 August 1988 [Ref 5; p. 6]. At the end of 1989, CALS added the discipline of 
concurrent engineering (CE) to incorporate the design process with weapon system 
production and logistics support processes. 
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At the same time, other digital information technologies, such as electronic 
commerce/electronic data interchange (EC/EDI), enabled the computer-to-computer 
exchange of business information. EDI dramatically reduces the costs of business 
transactions, largely by eliminating re-keying of data. EDI also provides the means to 
integrate business functions, enable process improvements, and establish extended 
enterprises. 

As CALS has grown, so has its acceptance and use by the international 
community. Government and commercial users have organized to develop CALS further 
in Europe and the Pacific Rim, as well as in the United States and Canada. In 1993, the 
definition of the acronym was changed once again to "Continuous Acquisition and 
Life-cycle Support." This most recent change was meant to reflect the fact that CALS is 
a strategy for information and process improvement, and that both are continuous. This 
latest focus recognizes CALS as a facilitator for world-wide process improvement and 
enterprise integration. [Ref 6, p. 17] 

2. CALS Development Strategy 

MIL-HDBK-59B clearly states the military aspects of the primary goal of the 
CALS as "to migrate from manual, paper-intensive defense system operations to 
integrated, highly automated acquisition and support process" [Ref 7; p. 4]. A target of 
these automated and integrated processes will be the Integrated Weapon Systems Data 
Base (IWSDB). Figure 1 shows how the IWSDB is accomplished throughout the life of a 
defense system. 

First, to support uniform integrated and interrelated digital-based functional 
processes among all services and the Defense Logistics Agency (DLA), the infrastructure 
- including computer hardware, software, and communication network capabilities — is 
required to be modernized under a standards-driven, open-system architecture, which 
gives interoperability' within industry and the DoD defense system. 
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Second, based on the modernized infrastructure, business process re-engineering 
is required in design, manufacturing, and life-cycle support of a defense system. 
Examples of the process improvements are direct coupling of design processes and 
integrated databases, elimination of duplicative, manual, error-prone processes, use of 
digital data, use of electronic data interchange, and development of integrated design and 
manufacturing capabilities with industry teaming arrangements. 

Third, migration from paper-based data to digital data will be accomplished by 
the use of common interfaces and neutral file formats, as defined in the standards and 
specifications that support information sharing and exchange across dissimilar computer 
systems. 

Finally, by implementing the previous three steps, logical data structure that can 
control and coordinate all technical information used to support a weapon system 
throughout its life-cycle will be accomplished by the IWSDB. DoD anticipates an 
effective shared environment where government and industry participate via this 
database concept. 
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Figure 1. Foundation for Creation, Management, and Use of Digital Data |Ref. 7) 


7 




Another definition of CALS is "a global strategy to further enterprise integration 
through the streamlining of business processes and the application of standards and 
technologies for the development, management, exchange, and use of business and 
technical information" [Ref 6: p. 18], This statement shows the industrial aspects of 
CALS as a strategy to find the most efficient way of doing business through sharing of 
standardized information by removing information barriers and redundant or unnecessary 
business processes via international coordination and cooperation. This tendency reflects 
the facts that CALS' domain is not necessarily limited in the relationship between DoD 
and the defense industry, and CALS is accepted by industry as a survival strategy in the 
highly competitive international business environment. 



Figure 2. The CALS Environment [Ref. 6: p.28| 

To implement an Integrated Data Base (IDB), CALS Industry Steering Group 
presented a similar approach to the government's [Ref 6]. In Figure 2, The outermost 
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ring indicates the necessity of business re-engineering from old business processes, which 
were estabUshed with paper formats and no longer apply in an electronic information 
environment. It is a client-centered approach, in which a workflow analysis is used to 
streamline or redesign the business processes and optimize organizational efficiency. The 
second outermost ring indicates that a redesigned organization's functional processes will 
be closely tied together to operate more efficiently by the use of enabling strategies, 
including Concurrent Engineering (CE), Computer Integrated Manufacturing (CIM), and 
Integrated Logistics Support (ILS). For the Networking and Data Exchange, which 
provides the role of electronic information bridge, the use of Electronic Commerce (EC)’ 
is suggested. Finally, to make an IDB work, establishment of Contractor Integrated 
Technical Information Service (CITIS), development of global data dictionary, and use of 
Configuration Management (CM) are also suggested. [Ref 6] 

3. CALS Standards and Specifications 

Standards are fundamental for CALS success. DoD CALS Evaluation and 
Integration Office is adopting and developing data and information standards and 
specifications to provide the common interface and neutral file formats necessary for the 
effective interchange and efficient use of digital technical data. DoD CALS policy on the 
CALS standards is to use existing and emerging national and international standards 
wherever possible to achieve this objective. 

Initially, CALS is focusing on standards for the electronic interchange of digital 
technical information among dissimilar computer systems. These initial CALS standards 
are intended to enable the digital delivery of engineering drawings, illustrations, technical 
manuals, and engineering data [Ref 8: p. 12-5]. 


' In this context, EC may include EDI, E-mail, electronic bulletin boards, electronic 
funds transfer (EFT), and other similar technologies. 
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Table 1. CALS Standards and Specifications TRef. 8: p. a-161 


DoD 

Industr>^ 

Applications 

MIL-HDBK-59 


Provide guidance on the technolog}, standards, and procurement process as 
related to the transition from a paper-intensive activity to one operating with 
digital information. 

MIL-STD-I840 


The primar}^ defense standardization document for the selected CALS 
standards. Identifies, b>^ application, which industr}^ standard and 
corresponding DoD standardization documentation to use. It also provides 
standard ’'enveloping” procedures for transferring standard data forms. 

MIL-D-28000 

IGES 

Initial Graphics Exchange Specifications (IGES) - A neutral file format for the 
representation and transfer of product definition data among CAD/CAM 
systems and application programs. 

MIL-M-28001 

SGML 

Standard Generalization Markup Language (SGML) - Markup requirements, 
tagging, and generic style specifications for page-oriented document text. 

MIL-R-28002 

CCITT 

GROUP 

4 

The efficient compression of scanned raster images. Uses the code from the 
group 4 facsimile recommendation of the International Telegraph and 
Telephone Consultative Committee (CCITT). A "tiled" form is described by 
using the architecture nomenclature of International Standard, ISO 8613. , 

MIL-D-28003 

CGM 

Computer Graphics Metafile (CGM) - A neutral format for the description, 
storage, and communication of graphical information. 

FIPS 161 

EC/EDI 

Electronic Commerce/Electronic Data Interchange (EC/EDI) - The electronic 
interchange of business information between trading partners. Uses standard 
formats currently defined by ANSI xl2 in the U.S., EDIFACT in Europe, and 
AECMA 2000 for NATO. 

ISO 10303 

STEP 

Standard for the Exchange of Product Model Data (STEP) - A computer 
interpretable data representation format being developed to include all product 
throughout its life C}xle. Product Data Exchange using STEP (PDES) is the 
U.S. standards activity supporting STEP. 

MlL-STD-974 

CITIS 

Contractor Integrated Technical Information Service (CITIS) - Contractor 
provided service for electronic access and/or delivery of contractually 
committed business and technical information on a need to know basis. 

MIL-M-87268 

lETM 

Prescribes the requirements governing the creation of Interactive Electronic 
Technical Manual (lETM) and the development of lETM presentation 
software applicable to a computer-controlled Electronic Display System 
(EDS). 

MIL-D-87269 

lETM 

Prescribes the interchange format for delivery^ of an lETM database to the 
Government. 

MlL-Q-87270 

lETM 

Prescribes the requirements for an lETM Contractor's Qualit} Assurance (QA) 
program. 

MIL-HDBK- 

SGML 

(draft) 

SGML 

Provides guidance in the application of MIL-M-28001, which is based on ISO 
8879, Standard Generalized Markup Language. Data prepared in accordance 
with these guidelines will facilitate the automated storage, retrieval, 
interchange, and processing of technical documents from varied data sources. 
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As CALS standards and specifications reflect the current trends and future 
directions for the fully integrated CALS digital environment, further standards will focus 
on complete product definition data, product models, and the need to access and manage 
data within distributed database environments to meet long term CALS capability (shown 
in the previous sub-section). Table 1 shows a list of DoD standards and their descriptions 
commonly used by industry as a reference for the CALS implementation. 

MIL-HDBK-59B presents two additional types of standards: other digital data 
interchange standards, and product, process, data integration standards. Certain industry 
standards for digital data interchange provide the opportunity for the acquisition of 
intelligent data necessary to support specific applications for defense systems. Table 2 
shows these standards and their applications. As these standards are not yet officially 
endorsed as CALS standards, they will be used by mutual consent between government 
and contraetor. 


Table 2. Digital Data Interchange Standards 


Standards 

Applications 

VHDL 

Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL) 

- ANSI/IEEE 1076. A formal notation intended for use in all phases of the creation of 
electronic systems. Supports the development, verification, synthesis, and testing of 
hardweu’e designs, the communication of hardware design data, and the maintenance, 
modification, and procurement of hardware. 

EDIF 

Electronic Design Interchange Format (EDIF) - ANSI/EIA 548-1988. Define the 
exchange of electronics product data between diverse CAD hardware and software. 
Designed to address all concerns shared by the electronic design community, including 
simulation models, schematics, and integrated circuit layouts. 

IPC-D-350 

Printed Board Description In Digital Form. Specify 80-character, fixed-length record 
formats used to describe printed-circuit board products with detail sufficient for tooling, 
manufacturing, and testing requirements. Transmit information in digital form between 
design and manufacturing facilities. 


In addition, product, process, and data integration standards reflect the present 
effort toward CALS implementation in the acquisition process on the integrated design. 
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development and manufacturing environment. Table 3 shows the military standards and 
their applications. 


Table 3. Product. Process, and Data Integration Standards 


Standards 

Applications 

MIL-STD-499 

Engineering Management. Assists in defining, performing, managing, and 
evaluating the systems engineering process efforts in defense systems acquisitions 
and technology developments. Implements technical essence of Concurrent 
Engineering and supports integrated product and process development. 

MIL-STD-881 

Work Breakdown Structure (WBS) for Defense Material Items. Establishes criteria 
governing the preparation and employment of WBS for use during the acquisition of 
designated defense materiel items. 

MIL-STD-973 

Configuration Management (CM). Sets forth CM practices that are to be tailored to 
specific programs and implemented by the contract SOW language. Applies 
technical and administrative direction over the life-cycle of configuration items, and 
describes in technical documentation the fimctional and physical characteristics of 
existing or planned hardware and software to meet product development and mission 
needs. 

MIL-STD-1388-1 

Logistic Support Analysis. Provides general requirements and task descriptions 
governing performance of logistic support analysis during the life-cycle of systems 
and equipment. 

MIL-STD-1388-2 

Logistic Support Analysis Report. Prescribes the data element definitions, data field 
lengths, and formats for LSAR data. Allows for delivery of LSAR data in manual or 
automated mode and on-line access to LSAR data as specified by the requiring 
authority. 


Since the initiation of CALS in 1985, continuous efforts to revise CALS standards 
have taken place in the guideline standards, neutral file format standards, or specific 
application related standards to match the rapidly advancing information technology and 
to reflect the result of tests being done on the current CALS standards. As CALS evolves 
toward integrated data bases, whether it is weapon system data base or industrial technical 
data base, it is wise to keep up with new drafts and amendments as they are issued. One 
example of these revising efforts was shown in the Bergmann memo, which allows the use 
of revised interface standards and performance specification without waivers [Ref 9]. 
Another example is the revision of MIL-STD-1840, which serves as a central standard for 
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the CALS environment. The next version of this standard is expected in late 1995 [Ref 8: 
p. 12-9], 

For its decade-long evolving history, CALS has developed new standards or 
adopted other commercial standards to keep up with the advance of information 
technology and industry trends. However, as a result of this history, there are some 
functional redundancies among these standards. It gives a selection problem to those who 
recently try to adopt CALS. A CALS-compliant standard does not mean that it is the 
most applicable standard for the particular requirement of application. For this reason, 
Knox et al. presented a way to categorize CALS standards [Ref 10: p. 67 - 71]. This 
categorization is summarized in Table 4. 


Table 4. Categorized Application Specific CALS Standards 


Category 

function 

example of CALS standard 

Data transportation 

Moving data form one location to another. 
Concerned mainly with error-free transfer of 
data. 

Content independent, (enveloping) 

ME.-STD-1840A 

TCP/IP (RFC 791/793) 

GOSIP (FIPS 146-1) 

Data management 

Storing, retrieving, and updating data. 

Cover language, data dictionary, distributed data. 
Content independent. 

SQL (FIPS 127) 

IRDS (FIPS 156) 

RDA (draft ISO standard) 

Data representation 

Formatting data in a standard manner. 
Interpretation of data 

Content dependent. 

EDI (FIPS 161) 

IGES (MIL-D-28000) 

SGML (MIL-STD-28001) 
Raster (MIL-STD-28002) 

CGM (MIL-STD-28003) 
PDES/STEP (ISO 10303) 
LSA/R (MIL-STD-1388) 


Data representation standards reflect the intensive effort of CALS to achieve 
automation and integration of data existing in the dissimilar formats. These are presented 
in Figure 3 by the relationship between information richness^ and requisite human 


^ Data is "information rich" in inverse proportion to the amount of human 
processing or intervention that is required to make the data useful. To require no human 
processing to generate data, there should be more products and actions. [Ref 10: p.67] 
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intervention. Thus, the use of different data representation standards depends on the 
different stages of product's life-cycle. For example, the more stages the product has, the 
richer the standard description of the product must be [Ref 10]. 



Figure 3. Information Richness, Human Processing Requirements, and Standards 

[Ref. 10: p. 69] 


B. CALS ENABLER 

1. Government/Industry Roles 

To achieve integrated data environment, collaboration for planning, managing, and 
implementing CALS between DoD and industry is definitely required. Figure 4 shows the 
various organizations, their role, and the relationships. The role of the DoD CALS 
Steering Group is to formulate CALS policy, to provide executive direction, and to 
implement the CALS program within DoD, whereas the role of the Industry Steering 
Group is to provide the focal point for CALS planning, technology and implementation 
concerns within industry. These two groups have been working together, holding joint 
meetings, and jointly acting as the corporate board of directors [Ref 5: p. II]. 
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Figure 4. The CALS Management Organization (Ref. 11] 


Charted DoD CALS organizations and other related government organizations 
take various roles to implement CALS strategy into their own domain. However, it is the 
responsibility of the DoD CALS Steering Group to provide coordination and guidance to 
ensure that there is no unnecessary duplication among the CALS acquisitions made by 
the DoD components. As mentioned in the previous section, to achieve IWSDB, the 
efforts of DoD should be concentrated on the modernization of its own infrastructure, 
coordination of DoD process improvement among all services and DLA, acquisition of 
digital data using commercial CALS technology, and continuous monitoring of the 
current implementation of the CALS vision. 

The Industry Steering Group (ISG) has several committees to cover many of the 
areas crucial to the success of CALS: concurrent engineering, information management, 
education and training, logistic process, small businesses, acquisition, and international 
considerations. These committees highlight areas in which further work has to be done. 
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such as information management, and they address topics of concern, such as the effect 
of CALS on small businesses [Ref 5: p. 16], Ongoing development of information 
technology toward integrated data environment and wide adoption of CALS as a strategy 
to improve business processes will make the role of ISG much broader, 

2. CALS Infrastructure 

Generally speaking, an infrastructure is a set of resources used by more than one 
information system. More specifically, the CALS infrastructure is the underlying 
foundation or basic framework required for the creation, exchange, management, and use 
of digital data in a CALS environment [Ref 7: p. 55], This underlying foundation 
required in a CALS environment includes computer hardware, software, and 
communication network capabilities. To achieve IWSDB, fundamental changes are 
required to modernize these components in the way DoD receives and uses technical 
data. To be able to receive, transmit, and utilize digital data in the management of 
weapon systems and related support activities, the DoD addressed two means of 
infrastructure modernization as: 

• Development of a joint service system that embodies the target system design 
and functional attributes and provides a fully encompassing infrastructure for 
evolving complementary system; and 

♦ Modification of existing and near-term planned systems for evolution towards 
CALS requirements and the target system concept. 

The efforts of DoD to modernize infrastructure toward a cost-effective CALS 
solution for acquiring and managing information by means of joint service system 
development are well reflected in Joint Computer-aided Acquisition and Logistics 
Support (JCALS) and Joint Engineering Data Management Information and Control 
System (JEDMICS). 
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JCALS is an information management system that is evolving to support uniform 
logistic, acquisition, engineering, manufacturing, configuration management, material 
management, and other life-cycle functional processes. The JCALS concept originated 
from the US Army's Technical Information Management System (TIMS), and then 
became the Army CALS (ACALS) program in March 1987. In January 1991, the Army 
was directed to transit ACALS to JCALS to include joint requirements and to make it a 
joint program. 

Actually, JCALS was designed according to CALS requirements and Corporate 
Information Management (CIM) Technical Reference Model (TRM) architecture. 
JCALS uses multi-weapon system IWSDBs and Global Data Dictionary/Directoiy 
(GDD/D) Services that are connected by a wide area computer network. The interface 
for users provides an environment to access all of JCALS's functionality transparently 
with a need-to-know and proper access privileges. To make JCALS more flexible and 
scaleable, and to avoid further major re-engineering, use of open system architecture 
standards, modular hardware, and data-driven modular software design is required. [Ref. 
7: p. 34] 

JEDMICS is a CALS-compliant repository for the storage of engineering 
drawings and related technical data. It originated from the Engineering Data 
Management Information and Control System (EDMICS) initiated by Navy. The 
EDM3CS program was validated as a program meeting the CALS initiative strategies and 
objectives in 1991, and selected as a tri-service program later that year. In 1993, 
EDMICS was chartered as a joint program by DoD, and renamed JEDMICS. JEDMICS 
consists of six subsystems^ that permit users on-line access to engineering drawings and 
related technical data stored in CALS data formats. These subsystems follow a standard 
open system design in a client-server architecture. The subsystems are scaleable and 
compatible with existing applications and information systems at a particular JEDMICS 
site. [Ref 12; p. 27] 

^ These subsystems are input, data integrity, index, storage, output, and remote 
output subsystem. 
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The modification of existing and near-term planned systems, suggested as a 
means to modernize DoD information infrastructure, is not an easy task. Prior to 
applying CALS to these systems, the characteristics of the program (i.e., program phase, 
type, size, and duration), the expected data conversion impact (i.e., data size, data 
sensitivity, required operating systems, and existing DoD infrastructure capabilities) and 
the result of cost/benefit analysis should be carefully considered. After these 
consideration, approaches on this modification will be (1) contract modification or (2) 
incentive programs that encourage the contractor and their subcontractors to undertake 
modernization projects [Ref 7: p. 29-32]. 

To reduce further bridging cost required to achieve IWSDB, the two approaches 
for infrastructure modernization should be closely coordinated by the use of open system 
standards and CALS data standards. Also, to achieve interoperability with industry who 
are providing the major input to the defense system, continuous evolution of common 
and consistent applications of Contractor Integrated Technical Information Service 
(CITIS) is required. 

3. Concurrent Engineering (CE) 

Concurrent Engineering (CE) is a systematic approach to the integrated, 
concurrent design of products and their related processes, including manufacturing and 
support. This approach is intended to cause the developers, form the outset, to consider 
all elements of the product life-cycle from conception through disposal, including 
quality, cost, schedule, and user requirements [Ref 7: p.54]. CE simultaneously defines 
the product, its manufacturing processes, and all other required life-cycle processes, such 
as logistic support. It is not the arbitrary elimination of a phase of the existing, 
sequential, feed-forward engineering process, but rather the co-design of all downstream 
processes toward a more all-encompassing, cost-effective optimum. [Ref 13: p. 55] 

This approach came from the recognition that conventional product development 
practices (i.e., sequential isolated design, and repeated iteration procedure to correct 
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design flaws) became progressively less efficient as product complexity and market 
demands increase. By considering all aspects of a product's life cycle simultaneously and 
cross functionally, CE gives significant reductions in product development cycles, a wide 
range of cost savings, and substantial improvements in product quality. As the 
integration of Reliability and Maintainability (R&M) with CAD/CAE is a high-leverage, 
high-payoff CALS target area and CE can support this integration, currently CALS/CE 
environment"* is espoused in the CALS policy. 

However, to achieve the benefits of CE, development of appropriate tools for 
design, manufacturing, and quality assurance, networking capabilities for the proper 
integration among all participants with adequate access control and, most importantly, 
cultural changes to break down various barriers among engineer, manufacturer, and end 
user should be precede this environment. 

4. Electronic Commerce/Electronic Data Interchange (EC/EDI) 

Electronic Commerce (EC) has been defined as the conduct of business 
transactions, supporting functions such as administration, finance, logistics, procurement, 
and transpxirtation, between the government and private industry, using an integrated 
automated information environment. Electronic Data Interchange (EDI) is one 
application of EC, defined as the electronic transmission of business information 
between two or more computers, across different computer platforms. 

As EC/EDI can handle on-line, timely exchange of digitized information required 
for routine business, the use of EC/EDI provides many benefits to both information 
provider and user, more specifically to suppliers and government. Thus, the goal of 
EC/EDI is to mold the vast network of small businesses, government agencies, large 
corporations, and independent contractors into a single community with the ability to 
communicate with one another seamlessly across any computer platform. 

"* The DoD stated that "Product, process, and data integration enhance a design, 
development, manufacturing, and support environment that demonstrates functionally 
integrated govemment/industry teams working with shared data." [Ref 7; p. 28] 


19 



To achieve this goal within DoD, a memorandum from the Deputy Secretary of 
Defense, dated May 1988, directed the maximum use of EDI and EC throughout DoD, a 
common approach to EC throughout DoD, and a single face to industry from all of DoD. 
The Defense Management Review Directive (DMRD) 941 EC/EDI, Implementation in 
the Procurement Process, dated November 1990, directed a very aggressive 
implementation schedule; 80% or more of their small-purchase contracts by the end of 
FY94 [Ref 14; p.62]. According to the Federal Acquisition Streamlining Act of 1994 on 
September 1994, signed by President Clinton, government-wide implementation of 
electronic commerce for appropriate Federal purchases to the maximum extent possible 
will be completed by January 1997 [Ref 15; p. 7], 

Although EC/EDI was not initiated by CALS, telecommunication networks 
capabilities give an excellent opportunity to exchange and establish common practices 
for business type data delivery (i.e., procurement processes) without paper flows. For the 
past ten years, industry has had the ability to transmit this digitized information through 
the American National Standards Institute (ANSI) X12 standards for various transaction 
sets, such as an 840 Request for Quote (RFQ) or an 850 Purchase Order (PO). However, 
the transaction set for transferring digitized technical information wasn't developed and 
accepted as a standard until October 1990. With the approval of the ANSI X12 841 
transaction set, which supports CALS-compliant technical and engineering data, and the 
issuance of FIPS 161 effective September 1991, contractors are able to incorporate 
technical data into RFQ in a CALS format in accordance with MIL-STD-1840 [Ref 14; 
p. 62]. The latest revision of CALS Implementation Guide stated the use of EDI as 
"FIPS PUB 161 summarizes the adoption of the families of interrelated software 
standards known as ASC XI2 and Electronic Data Interchange for Administration, 
Commerce, and Transport (EDIFACT) for electronic transmission of such data. The 
acquisition manager should consider taking advantage of this opportunity for program 
administration process improvements" [Ref 7; p. 17]. 
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5. Product Data Exchange Using STEP (PDES) 


The Standard for the Exchange of Product Model Data (STEP) is the familiar 
name for the international standard ISO 10303 Industrial Automation Systems and 
Integration Product Data Representation and Exchange. It is the international standards 
effort to develop a neutral mechanism capable of completely representing product data 
throughout the life-cycle of a product. The completeness of this representation makes it 
suitable, not only for neutral file exchange, but also as a basis for implementing and 
sharing databases and archiving. 

Though the official CALS specification for the CAD/CAE is IGES represented as 
MIL-D-28000, it has some drawbacks. First of all, IGES is not sufficient to cover all 
types of product data. This requires further revising efforts to develop subsets. Second, 
compared to CGM or STEP, the size of IGES data is relatively big, thus it is hard to 
deliver IGES file over current networks. A further drawback is that IGES addresses the 
exchange of product data only at the time of design work, not throughout the life cycle of 
the product [Ref. 5: p. 77]. STEP has potential capability to solve all of these drawbacks 
by providing product definitions covering the entire life-cycle, and supporting shared 
database environment. This is the reason why STEP is emphasized as a key element in 
the longer term CALS strategy for improving the productivity and quality of product 
design, manufacturing, and support. 

Product Data Exchange using STEP (PDES) is the U.S. effort to promote STEP. 
It ensures that U.S. industry requirements are incorporated into STEP, and provides 
methodologies for the implementation of STEP standards. The intent of this activity is to 
support the cooperative effort to produce a single international standard. So, when 
standard is represented, the term STEP is more preferable. 

STEP is a collection of standards, all covered under ISO 10303. They are divided 
into categories based on their function within the standards. The most important two 
categories are Generic Resources and Application Protocols (APs). The basic strategy of 
the STEP community is to create a set of APs that convert end-user requirements into 
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specifications that can be used to test conformance of vendor-implemented application 
software to the standard. The APs define the scope, the information to be exchanged, the 
means of testing, and a user's guide for implementing the application [Ref 16; p. 80], 
Generic Resources are used to develop the emerging APs by providing a generic set of 
basic product information entities such as tolerance, geometry, shape, material, drafting, 
and kinematics, 

STEP is still immature, although there are numerous STEP pilot projects 
progressing through various stages of completion. At the CALS Expo '94, Long Beach, 
only twelve parts were initially released as international standards. However, it is 
anticipated that STEP will be an important contributor to IWSDB via Contract Integrated 
Technical Information Service (CITIS). This is one reason why Smith suggested early 
use of STEP in CALS to ease the migration from IGES to STEP [Ref 5: p.80]. 

6. Integrated Weapon System Database (IWSDB) 

Integrated Weapon System Database (IWSDB) is the final target of the DoD 
CALS strategy to migrate from manual, paper-intensive defense system operations to 
integrated, highly automated acquisition and support processes. The concept of IWSDB 
is the construction of a single, logical database which contains all technical information 
used to support a weapon system throughout its life-cycle. The DoD states that this 
database concept will provide the basis for government and industry to participate in an 
effective shared environment [Ref 7: p. 5]. Figure 5 shows the concept of the IWSDB. 

IWSDB is a multi-weapon systems repository that services all the functions 
related to product design, engineering analysis manufacture, and support. To match the 
concept of store-once-use-many-times, there will be vertical access to data bases within a 
single weapon systems, and horizontal access to data bases across different weapon 
systems [Ref 5: p. 52]. 
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Figure 5. IWSDB [Ref. 5: p. 52] 

In order to ensure data integrity and reduce data redundancy, the IWSDB will be 
supported by a data dictionary and data directory upon logically collected distributed data 
bases. The Global Data Dictionary and Directory (GDD/D) database is one approach to 
accomplish this goal. The GDD/D database will serve as a repository of data management 
policy and data integrity requirements for data stored in IWSDB [Ref 7; p. 35]. In the 
JCALS system, the services required to access and manage the distributed data of the 
IWSDB will be provided by the Global Data Management System (GDMS). 

The technology for interfacing between information providers and users continues 
to evolve. The Contractor Integrated Technical Information Service (CITIS), which is a 
contractor-developed service which provides electronic access to or delivery of 
contractually required CDRL to user, is a current DoD guidance for the bi-directional 
interface between government and industry. Also, the government encourages industry to 
use CITIS for a high degree of information integration across the enterprise and business 
partners. Although CITIS provides options for the on-line access and delivery of digital 
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data, current telecommunications capacity and relatively large size of engineering 
drawings make it ineflBcient, However, use of the mature STEP will support the IWSDB 
not only by reducing actual file size but also providing product definitions throughout the 
life-cycle of weapon system. 

Smith stated that configuration management of technical information is another 
key issue [Ref 5: p. 55], The government could choose to have interactive access to the 
different types of data (i.e., working, released, submitted, and approved) in the CITIS 
rather than accept it as a deliverable. There are many aspects to configuration 
management; for example, the contractor will have to maintain in his status accounting 
system a complete change history for data files. As one of the product, process, data 
integration standards, MIL-HDBK-59B presents MIL-STD-973 Configuration 
Management (CM). 

When integrity of information is increasing, the fear for the secrecy and privacy of 
information is increasing, too. One of the most challenging goals is to provide reasonable 
protection on the IWSDB. For protection, the DoD suggested that "enforcement will be 
by a multi-level secure (MLS) trusted computing base (TCB) rated initially at B1 level of 
trust and progressing to B3 level." [Ref 7: p. 34] Even though this statement of security 
policy is ensured on the operating system and telecommunication, the extensive data 
sharing between contractors, subcontractors, and government activities will introduce 
legal issues (e g., proprietary data rights (who owns the data when), sharing licensing, 
warranties and liabilities, and international data exchange). Thus, consideration on the 
data rights throughout a product's life-cycle should be done in the early stage of each 
contract. 
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III. CALS TELECOMMUNICATIONS PLAN 


CALS is intended to automate technical data and drawing deliverables, including 
technical manuals and CAD/CAM products. During its evolving history, CALS has 
included many new areas, such as Concurrent Engineering (CE) and Electronic 
Commerce/Electronic Data Exchange (EC/EDI), to match the advance of Information 
Technology in the weapon system acquisition processes. To achieve full benefits of these 
new approaches, real-time on-line data transmission requirements and interoperable 
telecommunications protocols are very critical. Thus, adequate telecommunications 
capability, based on open system architecture, must be available, along with neutral data 
exchange standards. This chapter briefly describes the current situation of CALS data 
exchange, telecommunications capability, and standards. 

A. INTRODUCTION 

1. Phased Approach 

Automated standardized data coupled with real-time means of access will lower 
procurement and support costs, increase efficiencies, and result in a greater ability to 
disseminate and reuse data. To accomplish this, CALS must provide an integrated 
telecommunications system that can deal with enormous CALS technical data transmission 
requirements, regardless of the location of those data. The main direction of DoD for the 
CALS telecommunications architecture is the migration to Open Systems Interconnection 
(OSI), which is consistent with the overall CALS plan. For full CALS implementation, 
Doby [Ref 20] recommended a three phased approach; 

• Near Term (1989 - 1990). In the near-term, special attention should be given to 
the local environment because the bulk of data transfer over geographically 
dispersed areas will generally be accomplished offline in this timeframe. Usage 
of DDN should be limited to high-priority/low-bandwidth transmissions. 



• Mid Term (1991 -1992). The ability of the DDN to support all the required 
protocols should become available during the mid term; however, its use should 
still be restricted to high-priority/low-bandwidth transmissions. 

• Long Term (1993 - 1994). The long-term phase will include the addition of the 
higher bandwidth physical media required to support on-line transfer of bulk file 
data associated with CALS projects. 

Doby also anticipated the utilization of Integrated Services Digital Network 
(ISDN) for the long-haul connection after 1994. Yet his plan was too optimistic and 
on-line transmission of the CALS technical data is still not popular. Contributing factors 
come from several areas: Open System Interchange (OSI) standards, long-haul bandwidth, 
network security, and trends of industry telecommunication. These reasons will be 
covered in following sections. 

2. Data Delivery Methods 

On-line interactive access to the CALS data repository (e g., IWSDB) is the goal 
of CALS. This provides immediate and timely data access for custom report generation, 
document generation, and on-line request of information transmitted as composed 
products and processable data files. On-line transmission of the full volume of CALS 
technical data through existing telecommunications architecture is technically feasible, but 
it is not a cost efficient method because an extremely large amount of data transmission 
requirements caused by engineering drawings can easily overrun current 
telecommunication networks in DoD and industry. 

It is stated in MIL-HDBK 59B that, in near term, telecommunications may be 
limited to electronic mail exchange of high priority technical data, or other clearly defined 
uses such as CITIS access [Ref 7: p. 16]. Therefore, until full development of the 
nationwide information infrastructure, both physical delivery and on-line access/delivery 
will be used in the CALS data transmission. 

Physical delivery includes delivery of magnetic disks, magnetic tape, or optical 
disks used to transfer CDRL items to a government site. Magnetic tape is a mature. 
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stable technology that is able to handle the large volumes of data typically associated 
with a major defense system acquisition. MIL-STD-1840B provides a guidance for the 
use of hard copy forms of physical delivery by standardizing formats for exchange of 
digital information between DoD and industry. 

On-Line Access/Delivery is currently governed by MIL-STD-974 (CITIS). It is a 
contractor-developed service that provides electronic access to and/or delivery of 
contractually required Contract Data Requirements List (CDRL) data to users. CITIS is 
intended to be an efficient, contractually implementable means for providing the 
government with on-line access to contractor-generated data. Government Furnished 
Information (GFI), and the electronic transfer of such data. Ultimately, CITIS will 
replace most contractor delivery of hard-copy information currently required by the 
government throughout the program life-cycle [Ref. 18]. However, the current 
insufficient long-haul telecommunications capacity limits the use of CITIS to high 
priority technical data and EDI. 

3. CALS Test Network (CTN) 

The CALS Test Network (CTN) was established by the DoD in 1988 to test, 
evaluate, and demonstrate the interchange and functional use of digital technical 
information of digital data using DoD's CALS standards. The CTN not only tests and 
evaluates the CALS standards, but also provides the testbeds for DoD and industry 
coordination by testing applications of vendors. To demonstrate interoperability of 
CALS standards, MIL 28000 series of military specification are currently under testing. 
This tests and demonstrates the movement and interchange of technical data by 
comparing the transmitted data against received data. The participants of the CTN are 
various; government, industry, academia, and international. 

Yet, the CTN is used as a logical network, where most of interchanges are 
achieved by means of magnetic tape or optical disk, as required by MIL-STD-1840 [Ref 
5: p.89]. For the real-time on-line delivery test, physical links are achieved using the 
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DDN and various proprietary networks until the telecommunications capacity is large 
enough for the CALS technical data transmission. 

Test of the on-line CALS data transmission is shown in the CALS Electronic Data 
Interchange (EDI) Test/Demonstration supported by Air Force CTN. This demonstrated 
an electronic alternative to the current paper-based Request for Quotation (RFQ) process. 
RFQs, containing CALS technical data from the Engineering Data Computer Retrieval 
System (EDCARS), were sent via EDI to potential bidders to determine their capability 
to receive the RFQs and display the CALS engineering drawings clearly enough to allow 
bid submission. [Ref 19; p. 10] 

Although there is a limitation on the current networks capacity, the efforts to test 
and evaluate CALS standards (including new approaches such as EDI and STEP) should 
be continued, not only between government and industry, but also within industries to 
accomplish fully automated and integrated CALS environment. 

B. DATA EXCHANGE REQUIREMENT 

The final goal of the CALS approach is the accomplishment of the IWSDB, 
which services multiple acquisition and logistic functions. As the IWSDB is a logical 
multi-weapon system repository, the requirement of CALS data transmission may be 
various depending on the locations of physical data repository and the types of CALS 
data related to the phase of weapon systems life-cycle. During the telecommunications 
planning for CALS, these data transmission requirements may provide a guidance to the 
decision of physical LAN and WAN types. Furthermore, the comparison between CALS 
data transmission requirement and physical telecommunications capacity gives the basis 
for the cost-effectiveness of on-line data delivery', even in the long term. For this reason, 
Delaura et al. showed intersite data flow requirements [Ref 20], To support further 
research of the data flow analysis targeting a specific weapon system, this section 
provides basic decision rules required to select CALS data types and related CALS 
standards based on the CALS Implementation Guide (MIL-HDBK-59B). 
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1. Technical Manuals 


Technical Manuals (TMs) are the operating and maintenance instructions for 
military technicians. They contain a combination of textual narrative and illustrative 
graphic images presented in a formal, structured, page-oriented format governed by 
specific functional standards [Ref 7: p. 62], These manuals are one of the biggest burdens 
in the paper-based weapon system support. The implementation of automated data 
processing technology offers numerous improvement opportunities in preparation, 
delivery, storage, distribution, and maintenance of technical manuals. Digital 
representation of these technical manuals are as follows: 

a. Composed Document Image File 

This file is a static, formatted presentation of the manual, which can be 
archived, viewed, and printed only after receipt of the file. Two examples of digitally 
composed document files are Page Description Language (PDL), such as PostScript, and 
raster (MIL-R-28002). They provide a two-dimensional image of each manual page. 
Although these options convert a paper copy of legacy data to a digital one, on-line 
delivery of large size of raster document image and raster graphics files is not preferable 
even in the future. 

b. Processable Text and Graphics File 

For processable text, MIL-M-28001 (SGML) is the guiding CALS 
standard that governs the Document Type Declaration (DTD) and the Formatting Output 
Specification Instance (FOSI). A DTD is required to completely and rigorously describe 
the document's structure and content when FOSI is required for document's formatting. 

For processable graphics in a technical manual, MIL-D-28000 (IGES) and 
MIL-D-28003 (CGM) provides vector representation of graphics. The file size of both 
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standards is smaller than raster. The DoD stated that CGM is more preferable option to 
IGES because of its relatively small size of graphics file [Ref 7: p. 66]. 

c Interactive Electronic Technical Manual (lETM) 

Currently guided by MIL-M-87268, MIL-D-87269, and MIL-Q-87270, an 
EETM is a computer-based collection of technical information needed for troubleshooting 
and maintenance of a defense system. It presents interrelated information from multiple 
sources, tailored to user queries in a hypertext format. Thus, it can be a hypermedia 
document that permits the end-user to locate any information, such as text, graphics, 
audio, or computer programs, to present it faster and more comprehensively, regardless of 
the physical data repository. It has a potential capability to replace all paper-based TMs 
with less storage requirements. 

On the basis of telecommunications planning, however, LAN and WAN 
capacity should support real-time, on-line data delivery. As it is an emerging approach 
toward a high-payoff area based on the CALS environment, further revision of lETM 
specification is anticipated. 

2. Technical Data Packages 

A Technical Data Package (TDP) is a technical description of the product’s design, 
manufacture, quality assurance, and packaging characteristics adequate for procurement. 
More specifically, the technical description of an element of TDP consists of all applicable 
technical data, such as engineering drawings and associated lists, product manufacturing 
specifications and standards, performance requirements, quality assurance provisions, and 
packaging detail. The digital, deliverable form options for product drawings and 
associated lists are as follows: 
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a. Raster Image Files 


Raster Image files provide a representation of digitally scanned paper 
drawings or aperture cards. Guided by MIL-R-28002, it is not a machine intelligible 
format, and the data can't be processed within a raster image. As mentioned earlier, the 
large file size of this option makes the on-line delivery uneconomical. 

b. CAD Data Files 

These files consist of vector data with geometrically accurate and precise 
representations of the product, together with associated aimotations (e.g., dimensions and 
tolerance). To make them processable in future usage, MIL-D-28000 (IGES) should be 
used. Subsets of IGES will specify dimensions of CAD data. 

c. Product Data Files 

In addition to CAD data files, product data files are another processable 
files in the TDP category. It is more complete and flexible delivery option and also 
provide a methodology for linking CAE and support processes. Depending on the 
characteristics of product, the DoD showed various options of standards for product data 
files: SGML for non-graphic data, VHDL for digital functional design, EDIF for circuit 
performance description, and EDIF/IPC/IGES for manufacturing data package [Ref 7; p. 
70]. 

ISO 10303, also known as STEP, is one possible option in this category. 
Although it is an emerging standard in industry, its powerful technical structure and 
ability to create and define data models make STEP more capable of putting together all 
the aspects of product data in a shared database environment with a relatively small file 
size. 
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3. Logistic Support Analysis Records (LSAR) 


Logistic support analysis builds upon data from related systems engineering and 
design analysis, and produces a consolidated and integrated set of logistics-related 
technical data. The resulting LSAR is a logically integrated database consisting of both 
the engineering source data upon which analysis tasks are based, and the analysis results. 
The total set of data elements making up an LSAR database is defined by 
MIL-STD-1388-2. Because of the range of data that can be documented in an LSAR, the 
LSAR is able to satisfy the data requirements of a number of the deliverables commonly 
appearing on a Contractor Data Requirements List (CDRL), such as Provisioning Lists 
and Failure Modes, Effects, and Criticality Analysis (FMECA) reports. On-line 
interaction between the government and contractors enables more accurate LSAR data. 
LSAR data can be delivered as LSAR reports or LSAR data files: 

a. LSAR Report Image Files 

These files are the digital equivalent of the LSAR data in hard copy, and 
can't be updated or processed further after deliver}'. The delivery of LSAR reports in the 
image file format is guided by MIL-STD-1388-2. 

b. LSAR Data Files 

The basic format used for LSAR data files is alphanumeric. Because it is 
a processable format guided by MIL-STD-1388-2, the on-line delivery' of the LSAR data 
files can be only changed data tables (showing the difference from the previous submittal 
of the LSAR data), thus may reduce on-line transmission requirements. 

The DoD showed another delivery option for the LSAR data files, ISO 
10303 (STEP) [Ref 7: p. 73]. The capability to describe all the aspects of product data 
enables the use of STEP even in the LSAR data delivery. However, the use of this 
integrated data file is a future option presently under development. 






4. Training Products 


Most of the training products contain a combination of textual narrative and 
illustrative graphic images presented in a formal, structured, page-oriented format. 
MIL-STD-1379 contains detailed guidance for delivery of Interactive Courseware (ICW) 
and other specific training deliverables. The LSAR database shall provide source data to 
ICW for producing output reports and instructional materials [Ref. 8: p. 8-11]. 

a. Document Image File 

This file consists of composed page images of the full training product. 
Each page image represented by a two-dimensional image is guided by MIL-R-28002 
raster standard or Page Description Language (PDL). The impact of document image 
files on long-haul on-line delivery is the same as technical manuals. 

b. Processable Data File 

The processable data file is composed of one set of files for textual data, 
and a separate set of graphic illustrations or drawings. At present, the format of text file 
is defined by MIL-M-28001 (SGML) with appropriate DTDs, and the graphics format is 
defined by MIL-D-28000 Class I subset or MIL-D-28003 CGM. For training purposes, 
CGM is more a preferable option than IGES. 

c. Future Options 

As the range of training products is not limited in paper-oriented tutorials, 
the multimedia, such as video and audio clips, and/or pageless training products will soon 
appear in this category. However, to support these options, additional data sets in the 
LSAR database, large bandwidth in the networks, and appropriate software tools are also 
required. 
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5. EC/EDI 


EDI is the intercompany, computer-to-computer exchange of business documents 
in standard electronic data formats. These electronic transactions include invoices, 
shipping schedules, advance ship notices, court filing, bills of lading, and purchase orders. 
Rather than E-mail, which can use free-formatted message-length unit, EDI uses 
predefined, fixed-format message-length units known as EDI transaction sets. The 
Federal Information Processing Standard (FIPS) 161, published by NIST in 1991, 
suggests the use of either UN/EDIFACT or the ANSI ASC XI2. The global use of 
Internet promotes EDI as one of the best solutions to replace paper-based business 
transactions. The actual size of an EDI message varies depending on transaction sets. 
Yet, the relatively small size of EDI messages are allowable even through the current 
commercial Internet. 

C. CALS TELECOMMUNICATIONS STANDARDS 

1. International Standards (OSI) 

If different vendors use different data formats and data exchange conventions, the 
communication among these heterogeneous machines will be extremely difficult. To avoid 
this problem, and to give a common set of conventions in the software development, the 
International Organization for Standardization (ISO) established a subcommittee to 
develop an architecture in 1977. The result was the Open Systems Interconnection (OSI) 
reference model, adopted by ISO in 1983, which is a framework for defining standards for 
linking heterogeneous computers. The purpose of this effort is to provide a common basis 
for the coordination of standards development for the purpose of systems interconnection, 
while allowing existing standards to be placed into perspective within the overall 
Reference Model [Ref 21; p. 437]. 
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Table 5. OSI Reference Model 


Layer 

functions and capabilities 

Application Layer 

Allows for protocols and services required by particular user-designed application 
processes. Functions satisfying particular user requirements are contained in this 
layer. Representation and transfer of information necessary to communicate between 
applications are the responsibility of the lower layers. 

Presentation 

Layer 

Specifies or, optionally, negotiates the way information is represented for exchange 
by' application entities. It provides the representation of: 1) data transferred between 
application entities, 2) the data structure that the application entities use, and 3) 
operations on the data's structure. This layer is concerned only with the syntax of the 
transferred data. The data's meaning is known only to the application entities. 

Session Layer 

Allows cooperating application entities to organize and synchronize conversation 
and to manage data exchange. To transfer the data, session connections use 
transport connections. During the session, session services are used by application 
entities to regulate dialogue by ensuring an orderly message exchange on the 
session connection. 

Transport Layer 

Connection-oriented service provides reliable, transparent transfer of data between 
cooperating session entities. The transport layer entities optimize the available 
network services to provide the performance required by each session entity. 
Optimization is constrained by the overall demands of concurrent session entities 
and by the quality and capacity of the network services available to transport layer 
entities. In the connection-oriented transport service, transport connections have 
end-to-end significance, where the ends are defined as corresponding session 
entities in communicating end systems. Connection-oriented transport protocols 
regulate flow, detect and correct errors, and multiplex data, on an end-to-end basis. 

Network Layer 

Provides message routing and relaying between end systems on the same network or 
on interconnected networks, independent of the transport protocol used. The 
network layer may also provide hop-by-hop network service enhancements, flow 
control, and load leveling. Services provided by the network layer are independent 
of the distance separating interconnected networks. 

Data Link Layer 

Provides communication between two or more (multicast service) adjacent systems. 
This layer performs frame formatting, error checking, addressing, and other 
functions necessary to ensure accurate data transmission between adjacent systems. 

Physical Layer 

Provides a physical connection for transmission of data between data link entities. 
Physical layer entities perform electrical encoding and decoding of the data for 
transmission over a medium and regulate access to the physical network. 


The OSI Reference Model uses seven functional layers. The functions and 
capabilities expected at each layer are specified in the reference model. However, the 
model doesn't prescribe how this functionality must be implemented. Table 5 shows the 
general services provided by each layer in the reference model. 
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2. GOSIP 


Government Open System Interconnection Profile (GOSIP) is based on 
agreements reached by vendors and users of computer networks participating in the 
National Institute of Standard and Technology (NIST) Workshop for Implementors of 
OSI. It defines a common set of OSI data communication protocols that enable systems 
developed by dififerent vendors to interoperate and enable the users of different 
applications on these systems to exchange information via communication links. Based on 
the International Standards Organization OSI reference model, GOSIP has been 
designated Federal Information Processing Standard (FIPS) 146 in 1988. The new 
version of GOSIP (FIPS 146-1) was published in April 1991 to provide a remote terminal 
access capability and extended interoperability [Ref 22]. GOSIP mandates that 
government agencies, when acquiring computer networking products, purchase OSI 
capabilities in addition to any other requirements. 

CALS adopted GOSEP as a future standard for telecommunications media access 
and delivery standards. Another reason of this adoption was that GOSIP was consistent 
with, and complementary to, industry's Manufacturing Automation Protocol (MAP) and 
Technical Office Protocol (TOP) which adopted OSI protocols. MIL-STD-1840B states 
that "GOSIP will be able to interoperate with the DoD protocols; it is therefore, 
encouraged that acquisitions of telecommunication products require the delivery of 
systems that satisfy the data communication protocol specifications of GOSEP." 

3. TCP/IP 

Before OSI reference model and protocol suites were developed. Transmission 
Control Protocol and Internet Protocol (TCP/IP) provided the only practical method for 
computers from different manufacturers to communicate. TCP/IP were originally 
developed as part of the Advanced Research Projects Agency Network’ (ARPAnet) in the 

’ An experimental network designed to support military research to build networks 
that could withstand partial outages (e g., bomb attacks) and still function. 
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early 1970s. Compared to the complex OSI protocol suite, the TCP/IP protocol suite is 
relatively simple, hence provides easy interoperability among heterogeneous computers. 

At present, TCP/IP is the most favorite protocols in industry and government. 
Olsen showed the result of a survey presenting the dominance of TCP/IP over OSI [Ref. 
23]. As large, heterogeneous networks have grown up over the past several years, the 
leading mainframe, midrange, and microcomputer vendors all have been forced to 
incorporate TCP/EP into their product offerings. The explosive growth of commercial 
Internet connections also largely contributes to the growng population of TCP/IP stacks. 

Although CALS adopted GOSIP as a strategy promising ubiquity above various 
communication hardware and software, in reality, it had partially supported the 
proliferation of TCP/IP by mandating the DDN compatibility for its intermediate step. As 
the DDN is based on TCP/IP, the contractor should provide the appropriate number of 
DDN interfaces for each host, node, or LAN in addition to OSI suite [Ref 13: p. 179]. 
The result is that TCP/IP are still used when GOSIP is not. 

Quarterman stated that "GOSIP never required anyone to actually use OSI, just to 
procure it. Most every vendor also supplies TCP/IP, and that is generally what is actually 
used." [Ref 24] Now GOSIP is not a mandatory specification in acquisitions of products 
and services for communications between dissimilar computer systems. According to the 
recommendations of the final report of the Federal Internetworking Requirements Panel 
(FIRP), dated May 31, 1994, GOSIP was renamed to the Profiles for Open Systems 
Internetworking Technologies (POSIT), and mandatory compliance to OSI was changed 
to strong encouragement to "open voluntary standards." [Ref 25] 

In spite of TCP/IP's strength as a transport protocol, the OSI model's application 
layer X.400 message handling service and X.500 directory service protocols are gaining in 
popularity. The current trend of E-mail software vendors is to interface two different 
protocols together. On the basis of CALS telecommunications planning, the selection 
decision between two different protocol suites should reflect the interoperability to 
integrate islands of automation. 
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4. Multiprotocol Interoperability 


Instead of selecting one protocol suite as a dominant telecommunications 
protocols, the use of gateway gives interoperability between OSI and TCP/IP. As 
mentioned earlier, the communication gateway option in the CALS telecommunications 
plan was intended to convert TCP/IP protocols to GOSEP protocols for a limited time 
period required for migration from TCP/IP to OSI protocols. Now the situation is 
changed. The TCP/IP protocols are widely used for the internetworking; hence, they may 
provide the most promising interoperability option. However, the same gateway option 
presented in the CALS telecommunications plan will be used to support partial OSI 
applications, such as X.400 and X.500 protocols. 

Gateways can be grouped in various ways. A common general grouping scheme 
uses the attributes on which the gateway sevices operate: an address gateway, a protocol 
gateway, and a format gateway. [Ref 26: p. 420] 

• Address Gateway: Connects networks that have different directory spaces but 
that use the same protocols. This type of gateway is common, for example, 
when dealing with a Message Handling Service (MHS). 

• Protocol Gateway: Connects networks that use different protocols. This 
gateway does the protocol translations. 

• Format Gateway: Connects networks that use different representation schemes 
(e g., ASCII versus EBCDIC). The gateway maps between the two formats. 

To support X.400 with TCP/IP protocols, a protocol gateway can be used. An 
example of the gateway function to translate OSI protocols to TCP/IP protocols is shown 
in Figure 6. 

The use of ISO Development Environment (ISODE) software provides another 
option without using a gateway to translate different protocols. By locating an ISO 
transport level protocol interface on top of TCP/IP, higher-level OSI protocols can be 
directly used like other TCP/IP applications [Ref 27: p. 494]. 
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Figure 6. E-Mail Gateway between OSI Protocols and TCP/IP Protocols 

Although this thesis only reviews TCP/IP and OSI protocols for the 
interoperability of CALS telecommunications, there are also other protocols already 
developed and used at present. Thus, the enforcement of using TCP/IP with gateway 
options can not provide an ubiquitous solution for the all the areas of internetworking. In 
the long-term telecommunications plan for interoperability, a unique way to solve those 
multiprotocol networks should be provided to meet diverse user requirement. For this 
reason, Clark suggested that the next generation Internet Protocol (IPng) should have 
features that support its use with a variety of protocol architectures [Ref. 28]. So, it 
would be wise to keep up with new approaches to enable the maximum interoperability for 
the CALS telecommunications plan. 

D. CALS NETWORK INFRASTRUCTURE 

To support various CALS-related strategies, connectivity between government and 
industry and within government agencies is essential. This connectivity is achieved from 
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intrasite and intersite connection. In the beginning of the CALS telecommunications plan, 
CSMA/CD, which has a 10 Mbps capacity, was recommended for the intrasite connection. 

At present, FDDI is one of the popular options for the LAN. It gives 100 Mbps 
bandwidth with a high level of reliability. Although more bandwidth promises faster data 
transmission, a 10 Mbps to 100 Mbps capacity might be sufficient for CALS data 
transmission. 

The bottleneck comes from long-haul connectivity, which supports intersite data 
transmission. This is one reason why MIL-STD-1840 is providing off-line CALS data 
delivery. Although new technologies such as STEP promise less transmission 
requirements, the minimum capacity required by CALS data transmission on the intersite 
cormection should be provided. However, CALS strategy doesn't intend to install new 
network infrastructure; Currently available network infrastructure and near-term 
deployment of new infrastructure should be analyzed to enable on-line transmission of 
CALS technical data. 

1. DDN 

Operated by the Defense Information Systems Agency (DISA), the DDN is a 
packet-switched network designed to provide DoD with reliable, survivable, and secure 
worldwide communications. Established in 1982 as the DoD common-user data 
communications network, the DDN was based on ARPAnet packet-switching technology. 
The DDN enables computer systems and terminals/workstations acquired from different 
manufacturers to exchange information by using TCP/IP protocols. It currently offers a 
maximum user data rate of up to 56 Kbps. Based on the levels of security, the DDN 
currently consists of four separate networks; MILNET for unclassified communications, 
and DSNET 1-3 for classified communications. For CALS use of DDN, Delaura et al. 
assessed that the daily volume of intersite CALS data transmission would saturate the 
entire DDN, but DDN can provide partial CALS support [Ref 20: p. 2-8]. 
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2. DCTN 


The Defense Commercial Telecommunications Network (DCTN) is a 
satellite-based network that is used primarily for voice and video. It is a service that 
provides many major military locations with T1 (1.544 Mbps) transmission speeds. 
Managed by DISA (formerly DCA), the DCTN contract was awarded to AT&T in March 
1984. The service provides support for both dedicated and switched facilities, and can be 
reconfigured dynamically from a network control center. All transmissions and switching 
are digital. DCTN terrestrial links support switched voice, dedicated voice and data, and 
video conferencing. The bandwidth is divided into 24 voice channels of 56 Kbps each. 
Dynamic allocation of bandwidth is used to support video conferencing [Ref 20: p. 2-8]. 

The CALS community has been interested in DCTN, especially its general 
properties of satellite networks. However, before DCTN was analyzed for CALS data 
transmission, the focus of CALS telecommunications moved toward better service, such 
asFTS-2000 orDISN. 

3. DISN 

In June 1993, the Chairman of the Joint Chiefs of Staff (CFCS) ordered the 
establishment of the Defense Information System Network (DISN) with the original 
objective to achieve a single DoD worldwide common user IP router network. The CJCS 
directed all DoD Service/Agencies to use the DISN as the primary WAN for all DoD 
long-haul common-user telecommunications services. Currently, the DISN data service is 
composed of 86 hub routers, formerly the Defense Logistics Agency Corporate Network 
(DCN), and ten routers that provide the interconnection service for the DoD and 
non-DoD router network, formerly the DDN pilot Internet. [Ref 29: p. 40] 

At present, DISA plans evolutionary development of new DISN which is a global 
mega-network capable of handling voice and high bandwidth data such as imagery. It is 
envisioned as DISA operated and managed network running on DoD-owned switches 
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with pipes acquired competitively. DISA expects to end up with a Synchronous Optical 
Network (SONET) running on advanced Asynchronous Transfer Mode (ATM) switches 
[Ref 30; p. 37], It is anticipated that, after the completion of DISN, it will give much 
more flexibility to the on-line CALS data transmission. 

4. FTS-2000 

Federal Telecommunications System 2000 (FTS-2000) was established in 
December 1988 to provide long-haul communications for all government agencies. 
Managed by General Services Administration (GSA), FTS-2000 consists of two major 
contracts with AT&T and U.S. Sprint. Packet switched services for data transmission 
provides 56/64 Kbps dynamic connectivity. Dedicated transmission service for 
point-to-point private line services provides T1 (1.544 Mbps) connectivity. It also 
provides video transmission service for compressed video and full motion 
teleconferencing. The FTS-2000 backbone consists of switches that are interconnected by 
T3 (44.7 Mbps) fiber-optic links. The DoD plans call for using the FTS-2000, with the 
CALS network as one of the likely major users [Ref 2; p. 8]. The FTS-2000 contracts 
are due to expire in December 1998. 

5. Commercial Internet 

The Internet is the inter-networking of existing corporation and government 
networks using common TCP/IP protocols. Krol states that it was bom out of an effort to 
connect a U.S. Defense Department network called the ARPAnet and various other radio 
and satellite networks [Ref 31: p. 13]. Grown from NSFNET, originally commissioned 
by the National Science Foundation (NSF), the Internet provides an international-wide 
academic network. Recently, many corporations also take part in the Internet to have 
their nationwide corporate network. Now it becomes a network of networks connected 
by more than 40,000 networks and 4 million host computers around the world. 
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At a recent meeting in Toronto, Canada, the Internet Engineering Task Force 
(IETF) made a decision that could make the Internet the backbone of the information 
superhighway [Ref 32]. To support global use of the Internet, and to overcome the 
limitation on its current addressing structure, IETF is going to suggest a "next generation" 
Internet protocol (IPNG). 

Actually, the Internet provides the widest connectivity at less cost. Federal 
agencies and even military agencies use the Internet for their operations as an efficient and 
effective means of communication and information distribution [Ref 33]. The EDI using 
the Internet is a hot issue at present. However, the decision to use the conunercial 
Internet in CALS data transmission is not clear, because CALS technical data are not only 
extremely large, but they also include large portions of classified information. With more 
than current bandwidth provided by military networks, appropriate data protection 
methods should be developed and adapted. The Multilevel Information Systems Security 
Initiative (MISSI), sponsored by the National Security Agency (NSA) suggests one 
possible solution for the transmission of classified data through the public Wide Area 
Network (WAN). 

E. SUMMARY 

CALS is an extremely long-term project requiring a great deal of effort and money. 
Although the DoD carefully planned the phases of CALS telecommunications architecture, 
it was already overdue. Some of the plans are not matched with the current situation of 
telecommunications trends. To accomplish a successful CALS environment, timely and 
adequate alterations are important to overcome unexpected obstacles located on the way 
to automation and integration of infomation. However, the changes sometimes bring 
much more difficulties and registrations than the original situation. Thus, the initiation of 
the CALS telecommunicaions plan should be flexible enough to overcome any unpredicted 
difficulties. 
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At present, the Defense Ministry (MND) of Korea is trying to proliferate CALS 
with the cooperation of industry. The effort to implement CALS was begun much later 
than in the U.S., but the later start gives an advantage. On the basis of CALS 
telecommunications planing, the history of the United States approach shows some of the 
very important factors for successful CALS implementation. 

First of all, the network blueprints should be flexibly prepared. Networks are the 
fundamental infrastructure to implement CALS. However, it may not be separately 
constructed for the CALS implementation only. Currently the Korean MND is 
implementing a Ministry-wide computer network. It consists of backbone with T1 
capacity and other branching lines. It is far behind CALS data transmission requirements. 
The rapid proliferation of the commercial Internet gives one possible solution, but it 
should be equiped with appropriate network security policy and methodologies. The 
National Information Infrastructure (Nil) is another solution, yet it is too far. The law of 
economics suggests using current infrastructure, and providing bridges that connect the 
present situation with the future one. 

Second, the capacity required for the on-line data traffic should be analyzed. The 
network capacity depends on the weakest bottleneck of data transmission. In other 
words, insufficient capacity at one place in a network can impact entire network's 
capacity, and may require revision of the telecommunicational strategy. So, on-line data 
transmission and the actual location of the data should be carefully analyzed and designed. 

Third, the end user requirement should not be underweighed. Although CALS is a 
global strategy to enhance the information flows between the government and industry, 
the success of this approach may depend on the hands of end users who actually deal with 
it. Without a careful consideration of user requirements, the expensive investment on 
CALS implementation shall not pay off. 

Fourth, the direction of CALS implementation should be exact and specific. CALS 
can improve processes using information technology. But, too broad a scope results in 
poor management of the entire project. At present, the US. CALS strategy is returning to 
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its original goal, logistics support. It was criticized by Congress for spending 10 years and 
$ 5 billion and not showing any results. As a consequence, the Crovemment Information 
Enhancement is moving to Enterprise Integration (El), which promised tighter 
management of the automation and integration of information. 
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IV. NETWORKS SECURITY AND RELATED ISSUES 


In reality, CALS still prefers courier services to on-line data transmission. The 
reason for this preference is not only the extremely large file size for engineering drawings, 
but also the lack of security in networks carrying CALS technical data. The major 
concern about CALS data protection during the transmission is data encryption. As 
CALS technical data travel on the unsecured communication media, the data should be 
secure enough to protect themselves. However, the CALS implementation guide 
(MIL-HDBK-59B) and on-line information service guide (CITIS) still do not specify 

details of the encryption devices or software. 

At present, MIL-STD-1840B, which describes delivery methods of CALS data in 
magnetic tapes or optical disks, is the only option for the classified data delivery in digital 
format. According to the Tomlinson, the Army's JCALS program manager, about 10 
percent of CALS-related information is classified [Ref 34]. He was considering another 
island of information by removing the 10 percent of information to a separate JCALS 
workstation to control access to secure data. Thus, without adequate support of classified 
data transmission, a fully integrated CALS environment is still far away. 

As part of an effort to propose a secure CALS telecommunications architecture, 
this chapter analyzes the roles of network security and the ways of data protection in the 
CALS environment. 

A. INTRODUCTION 

1. Impact of Networks Security 

To accomplish a highly integrated CALS environment, internetworking among 
distributed systems, and the use the networks and communications facilities for carrying 
data are one of the basic requirements of the CALS implementation. But, when the range 
of systems has expanded, the vulnerability of the data transmitted among systems has also 
increased. 
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The term "network security" refers to protection against any unauthorized 
modification, disclosure, and destruction of network information, or loss of network 
service leading to the non-availability of critical information. Thus, the security issues 
that are raised regarding networks are more complex than conventional computer 
systems. The reasons for these increased security issues inherent in networks were 
shown by Pfleeger [Ref 35; p. 372]. 

• Sharing. Because of the resource and workload sharing of networks, more 
users have the potential to access networked systems than single computers. 
Thus, access controls for single systems may be inadequate in networks. 

• Complexity of System. A network operating/control system is likely to be more 
complex than an operating system for a single computing system because a 
network combines two or more possibly dissimilar operating systems with 
mechanisms for interhost connection. Thus, the certification of a network is 
more difficult than a single computing system. 

• Unknown Perimeter. The expandability of a network brings uncertainty about 
the network boundary. One host may be a node on different networks, so that 
resources on one network are accessible to the users of other networks as well. 
Although wide accessibility is an advantage, the unfixed boundary of networks 
may allow unintentional connection to potentially malicious users. 

• Many Points of Attack. When a file is shared by several different networks, it 
may pass through many different nodes from source to destination. Thus, the 
weakest point of nodes gives the best chance to disclose the secrecy of data. 
The enforcement of the access control mechanisms over all those networks is 
more difficult than a single computing system. 

• Unknown Path. Especially in packet-switching networks, there may be many 
paths from one host to another, as network users seldom have control over the 
routing of their messages. To cover all the possible paths by security’ 
mechanisms is not an easy task. 

As a result, networks make data more vulnerable to any potential threat than a 
single computing system. Privacy of data, data integrity, and authenticity of data are 
typical examples of the vulnerability’ expanded by networking. First, as mentioned 
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above, with many unknown users on networks, concealing sensitive data becomes more 
difficult. Second, because more nodes and more users have potential access to a 
computing system, the risk of data corruption is higher. Third, it is more difficult to 
assure the identity of a user on a remote system. To protect these vulnerabilities, 
adequate countermeasures should be employed. 

2. Security Attack 

A security attack is defined as any action that compromises the security of 
information owned by an organization [Ref 36. p.4]. It can be any action that threatens 
privacy, integrity, and authenticity of data. The types of attack can be categorized into 
passive attacks and active attacks. 

0 . Passive Attacks 

A passive attack is any action of eavesdropping on, or monitoring of, a 
transmission. It is called a passive attack because it is done without interfering with the 
data flow. The most fundamental type of passive attack is the "release of message 
contents". Another type of the attack is "traffic analysis". This type of the attack intends 
to obtain not the contents of message but other information useful in guessing the nature 
of the communication. Packet headers, for example, gives adequate information 
regarding th ' loeation and identity of communicating hosts. The length and frequency 
of messages provide the pattern of messages being exchanged. 

Passive attacks are very difficult to detect since they do not involve any 
alteration of the data. However, it is feasible to prevent the success of these attacks by 
isolating a network or using cryptosystems. Thus, the emphasis in dealing \vith passive 
attacks is on prevention rather than detection [Ref. 36: p. 8]. 
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b. Active Attacks 


An active attack, called active wiretapping, is any action related to 
interruption, modification, or fabrication of data. It can be subdivided into four 
categories: masquerade, replay, modification, and denial of service [Ref 36: p. 9], 

A "masquerade" takes place when one entity pretends to be a different 
entity. It usually includes one of the other forms of active attack. "Replay" involves the 
passive capture of a data unit and its subsequent re-transmission to produce an 
unauthorized effect. "Modification of message" means that some portion of a legitimate 
message is altered, or that messages are delayed or reordered, to produce an unauthorized 
effect. The "denial of service" prevents or inhibits the normal use or management of 
communications facilities. It can be the disruption of an entire network, either by 
disabling the network or by overloading it with messages so as to degrade performance. 

An active attack has the opposite characteristics of passive attack. It can 
be easily detectable, but difficult to prevent since the prevention means protection of 
entire networks. Thus, the emphasis in dealing with this attack is on detection and the 
recovery of data disrupted or delayed. The stalling states that the detection may also 
contribute to prevention because, the detection has a deterrent effect [Ref 36: p. 10]. 

3. Security Service and Mechanism 

Securit)' Service is a service that enhances the security of the data processing 
systems and the information transfers of an organization. Its actual role is to provide 
countermeasures against security attacks by using security mechanisms designed to 
detect, prevent, or recover from security attacks. Although many characteristics used in 
security service come from paper-based document protection, the nature of digital bits 
make the service more difficult. To provide security services, encryption acts as the 
most common means. However, encryption itself is not enough to provide all the 
services, so combination of other techniques and devices with encryption mechanisms 
are used to provide the security services. Stalling suggests one useful classification of 
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security services useful in network security; Confidentiality, Authentication, Integrity, 
Non-repudiation, Access Control, and Availability [Ref. 36: p. 10-12], 

a. Confidentiality 

This service is used to protect transmitted data from passive attacks. With 
respect to the release of message contents, several levels of protection can be identified. 
The protection mechanisms supporting this service are based on cryptographic 
techniques. In a network environment, link-to-link or end-to-end encryption can be 
provided. 


b. Authentication 

This service is concerned with assuring that a communication is authentic. 
In the case of a single message, the function of authentication service is to assure the 
recipient that the message is from the source that it claims to be from. In the case of an 
ongoing interaction, the function is to assure that the two communication entities are 
authentic, and the connection is not interfered by a third party who can masquerade as 
one of the two legitimate parties for the purpose of unauthorized transmission or 
reception. The protection mechanisms can be simple password schemes or cryptographic 
techniques attached in the hardware device, such as a token or smart card. 

c. Integrity 

This service provides proof of the integrity of data in the communication 
and can be used to detect and protect against the manipulation and modification of data. 
It is a service related to active attacks; thus, the detection mechanisms are used to 
provide the service. Integrity mechanisms employ cryptographic techniques to produce 
integrity checksums, which can be used to determine whether there has been any 
insertion, deletion, or reordering of the original sequence of messages. 
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(L Non-repudiation 


Non-repudiation prevents either sender or receiver from denying a 
transmitted message. It is a service to prove the origination and destination of a message 
to the receiver and sender, respectively. Digital signature mechanisms and/or one-way 
hashing functions are used to provide the non-repudiation service. 

e. Access Control 

Access control is the ability to limit and control the access to host systems 
and applications via communications links. Combined with authentication service, 
access control can be tailored to each of the access grants, depending on the 
classification of data and user to protect against the unauthorized use of resources. 
Discretionary access control and mandatory access control are the examples of this 
service. 


f. Availability 

A variety of attacks can result in the loss of or reduction in availability. 
Denial of service is usually regarded as an extreme case of these attacks. Thus, 
availability services are congregated services, including authentication, encryption, and 
other adequate physical actions to provide a seamless communications environment 
between two entities. 

B. FUNDAMENTALS OF DATA ENCRYPTION 

1. Introduction 

Encryption is a means of maintaining secure data in an insecure environment. It 
is the process of changing a message called plaintext to ciphertext. In a networked 
environment, encryption allows secure communication over an insecure channel. By 
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using encryption, the plaintext is disguised so that, even if the transmission is diverted, the 
message will not be revealed. Most of the security mechanisms used in networks are 
based on the data encryption, whether those mechanisms are provided by applications 
software or embedded in hardware devices. 

With respect to decrypting the encrypted message, encryption techniques can be 
divided into two categories: symmetric key cryptography and asymmetric key 
cryptography. In a symmetric cryptosystem (also called private key, single key, secret 
key, or conventional cryptosystem), both the encryption and decryption transformation 
use the same key. The security of the encryption method is dependent on the robustness 
of encryption algorithm. On the other hand, in an asymmetric key cryptosystem (also 
called public key cryptosystem), a pair of keys are used to encrypt and decrypt a message. 
By encrypting and decrypting with a separate key, asymmetric key cr 3 q)tography provides 
a better way to distribute and manage the keys than conventional cryptography. However, 
the transformation speed using asymmetric key cryptosystem is much slower than 
conventional cryptosystem, because of its complicated mathematical algorithm. 

For encryption, the best solution is to combine symmetric and asymmetric key 
systems in order to get both the security advantages of asymmetric key cryptography, and 
the speed advantages of symmetric key cryptography. For example, asymmetric key 
cryptography can be used to encrypt a secret key, which is then used to encrypt the bulk 
of a file or message. Fahn suggested that public key cryptography is not meant to replace 
secret key cryptography, but rather to supplement it, and to make it more secure [Ref. 37; 

p. 6]. 

The hashing function, also called message digest, is used as another means to 
assure the integrity of a received message. Usually combined with other cryptosystems, 
it usually supports data integrity by providing evidence whether the original message 
transmitted is altered or not. It is similar to symmetric cryptography because it uses the 
same scheme to produce a hashed message at sender's and receiver's computers, but the 
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difference is that the result of hashing is independent to the length of the original 
message. 

2. Secret Key Algorithm 

Secret key cryptography involves the use of a single key that is mutually shared by 
two communicating entities. Given a message and the key, encryption produces 
unintelligible data that is about the same length as the plaintext was. Decryption is the 
reverse of encryption, and uses the same key used for encryption [Ref 37; p. 45]. One 
major advantage of using a secret key algorithm is fast encryption speed, so large files can 
be quickly transformed to a cipher text and networks can transmit that file without any 
performance degrading. However, with a secret key algorithm, the key should be 
pre-exchanged before encryption, whether using a courier service or another key 
distribution technology. 

a. Data Encryption Standard (DES) 

Data Encryption Standard (DES) was published in 1977 by the National 
Bureau of Standards for use in commercial and unclassified U S. Government applications. 
It was based on an algorithm known as the "Lucifer" cipher designed by IBM in 1974. 

DES uses a 56-bit key, and maps a 64-bit input block into a 64-bit output block. The key 
actually looks like a 64-bit quantity, but one bit in each of the 8 bytes is used for odd 
parity on each byte. Therefore, only 7 of the bits in each byte are actually meaningful as a 
key [Ref 38: p. 60]. DES uses a substitution technique and a transposition technique, and 
these two techniques are repeated for 16 cycles, one on top of the other. The same key 
used in encryption is also used in decryption, but in the reverse order. DES can be 
efficiently implemented in hardware, but is relatively slow if implemented in software. 

A powerful technique for improving the security of DES is multiple 
encryption, that is, encrypting each message block under several different DES keys in 
succession. Triple encryption is thought to be equivalent to doubling the key size of DES 
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succession. Triple encryption is thought to be equivalent to doubling the key size of DES 
to 112 bits [Ref 37: p. 37], It can actually prevent any decrypting attempt, although it 
takes three times longer than single-encryption DES. Triple DES has been adopted for 
use in the key management standards ANSI X9.17 and ISO 8732, and for Privacy 
Enhanced Mail (PEM) [Ref 36: p. 67], 

b. International Data Encryption Algorithm (IDEA) 

IDEA is a new block-oriented, conventional encryption algorithm 
developed by Lai and Massey of the Swiss Federal Institute of Technology [Ref 38: p. 
74]. IDEA uses a 128-bit key to encrypt data in blocks of 64 bits. It has 17 rounds to 
encrypt each of 64 bits of message block. The 126-bit key is divided by 52 of 16-bit 
sub-keys, whereas the message is divided into four 16-bit sub-blocks during the 
operation. Like DES, IDEA uses a complicated mangier function that does not have to 
be reversible for decryption. 

IDEA is designed to facilitate both software and hardware 
implementation. Hardware implementation, typically in VLSI, is designed to achieve 
high speed, while software implementation has the advantage of flexibility and low cost. 
Currently, IDEA is used in Pretty Good Privacy (PGP), one of the secure e-mail 
applications. 


c. RC2 and RC4 

RC2 and RC4 are another type of well-known secret key cryptosystems. 
They are variable-key-size symmetric block cipher functions for fast bulk encryption. 
They are as fast or faster than DES. As they use variable key sizes, the comparison to 
DES in terms of strength depends on the key size. 

RC2 can be used in same modes as DES, including triple encryption. It is 
approximately twice as fast as DES, at least in software. RC4 is a variable-key-size 
symmetric stream cipher, and is 10 or more times as fast as DES in software. Both RC2 
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and RC4 are very compact in terms of code size. RC2 and RC4 have been widely used 
by developers who want to export their products [Ref 37; p.49]. 

3. Public Key Algorithm 

The first public key cryptography was invented in 1976 by Diffie and Heilman in 
order to solve the key management problem in secret key cryptography [Ref 36: p. 109], 
In this system, each person or communicating entity gets a pair of keys, called the public 
key and private key. Each person's public key is published or often posted on electronic 
bulletin boards, while the private key is kept secret. The need for sender and receiver to 
share a unique secret key is eliminated. All communications involve only public keys, 
and no private key is ever transmitted or shared. 

Currently available public key cryptosystems provide two additional applications: 
encryption/decryption and digital signature. In encryption/decrytion, the recipient's 
public key is used to encrypt a message by a sender so that only the recipient can deciypt 
the message with his/her own secret key. In digital signature, the sender's private key is 
used to sign a message so that the recipient can verify the identity of the sender by 
decrypting the message with the sender's public key. Signing is achieved by a 
cryptographic algorithm applied to the message or to a small block of data that is bound 
in some way to the message [Ref 36: p. 114]. At present, four public key cryptosystems 
are available, yet the use of those cryptosystems depends on their capability to serve 
applications. Table 6 shows those cryptosystems and their capability. 

Table 6. Applications for Public Key Cryptosystems IRef. 36: p. 1151 


Algorithm 

Encryption/Decryption 

Digital Signature 

Key Exchange 

RSA 

Yes; impractical for large blocks 

Yes 

Yes 

LUC 

Yes; impractical for large blocks 

Yes 

Yes 

DSS 

No 

Yes 

No 

Diffie-Hellman 

No 

No 

Yes 
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Public key cryptosystems are based on the trap-door one-way functions [Ref 37: 
p. 30], The public key gives information about the particular instance of the function. 
The private key gives information about the trap door. Whoever knows the trapdoor can 
perform the function easily in both directions, but anyone lacking the trap door can 
perform the function only in the one direction, usually for encryption. The strength of 
those functions comes from the complexity of the mathematical computation, such as the 
discrete logarithm and modular exponential algorithm. 

a. RSA 

RSA is named after its inventors, Rivest, Shamir, and Adleman. RSA has 
two important functions not provided by DES; secure key exchange without prior 
exchange of secrets, and digital signatures. The key length is variable. Anyone using 
RSA can choose a long key for enhanced security, or short key for efficiency. The most 
commonly used key length for RSA is 512 bits. The encryption block size in RSA is also 
variable. The plain text block must be smaller than the key length. The encrypted block 
will be the length of key. [Ref 38; p. 134] 

The premise behind RSA's security is the assumption that factoring a big 
number is very difficult. The best known factoring methods are really slow. To factor a 
512-bit number with the best known techniques would take about a half million 
MIPS-year [Ref 38: p. 135]. Even though a new factoring algorithm may be developed 
in the future, the extension of key size will make the security of RSA more robust. In 
fact, the weakness of RSA is found not from the algorithm, but from the poor 
management of the secret key, which is the same problem considered in other public key 
algorithms. 

RSA is much slower than any secret key algorithm. To encrypt a message, 
RSA is combined with a secret key algorithm, such as DES, by means of an RSA digital 
envelope. For encrypting messages, the message is first encrypted with a random DES 
key, and then, before being sent over an insecure communications channel, the DES key 
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is encrypted with RSA. Together, the DES-encrypted message and the RSA-encrypted 
key are sent [Ref. 37: p. 9], 

To release the burden of the actual RSA implementations in different 
situations, RSA provides the Public-Key Cryptography Standard (PKCS) and other 
helpful guides [Ref 38: p. 145], Composed of a set of standards, PKCS defines the 
encodings for things such as encryption and digital signing to help the software industry 
actually implement RSA into their applications. 

b. Digital Signature Standard (DSS) 

The Digital Signature Standard (DSS) was proposed by NIST in 
cooperation with the NSA as draft FIPS PUB 186 in 1991. In 1994, the U.S. Commerce 
Department approved the DSS as the mandatory standard for agencies using digital 
signature applications. The algorithm of the DSS is known as Digital Signature 
Algorithm (DSA). The DSA is based on the difficulty of computing discrete logarithms, 
and it is based on schemes originally presented by ElGamal and Schnor. [Ref 36: p. 344] 

The DSA provides signature generation and verification. Simply, signature 
generation is done with a sender's private key, and verification is done with a sender's 
public key by a recipient. The keys are generated by logarithmic manipulation of two 
large prime numbers, which are 160-bits and 512-bits long. The signing and verifying 
procedure uses another algorithm. Secure Hash Standard (SHS), to generate a condensed 
version of data called message digest. 

The DSA authenticates the integrity of the signed data and the identity of 
the signer. The DSA may also be used to prove to a third party that data was actually 
signed by the generator of the signer (signature certification). Although the DSS cannot 
be used for encryption or key exchange, it can be used for other applications which 
require data integrity assurance and data origin authentication. 
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4. Hash Function and Message Digest 


A hash function is a computation that takes a variable-size input and returns a 
fixed-size representation of input, which is called hash value. If the hash function is 
one-way (i.e., hard to invert), it is also called a message-digest function, and the result is 
called a message digest [Ref 37: p. 47]. A hash fimction can usually serve to detect 
modification of a message. For digital authentication, the function should avoid a 
collision (a situation where two distinct messages have the same hash value), and it 
should be infeasible to find a message that hashes a given value. Actually the robustness 
of a hash function comes from the length of the message digest. Thus, the size of the 
message digest should be reasonably long to avoid any attempt to attack the hashing 
algorithm. 

Although hash functions, in general, have many uses in computer programs, such 
as password encryption, in cryptography they are used to generate a small string (the 
message digest) that can represent securely a much larger string, such as a file or 
message. Since the hash functions are faster than the signing functions, it is much more 
efficient to compute a digital signature using a document's message digest than to use the 
arbitrarily large document itself Additionally, a digest can be made public without 
revealing the contents of the document from which it is derived. This is important in 
digital time-stamping, where one can get a document without revealing its contents to the 
time-stamping service [Ref 37; p. 47]. 

a. MD Series 

MD stands for Message Digest. At present, MD2, MD4, and MD5 are 
widely used hash functions for cryptographic purposes, which were designed by Ron 
Rivest, one of the inventors of RSA public key algorithm [Ref 37: p. 48]. 

MD2 takes a message equal to an arbitrary number of 8-bit bytes and 
produces a 128-bit message digest. Message inputs are padded with checksum, which is 


59 




a 16-byte quantity appended at the end of a message, then processed as a multiple of 16 
bytes. By its 8-bit-oriented characteristics of processing, it is the slowest among the MD 
series. MD4 was designed to be 32-bit-word-oriented so that it can be computed faster 
on 32-bit CPUs than in a byte-oriented scheme. MD4 can handle messages with an 
arbitrary number of bits. To produce 128-bit digest, each of 512 bits is passed three 
times through a hash function [Ref 38: p. 116]. 

MD5 is very similar to MD4, but is designed to be more conservative than 
MD4 in terms of being less concerned with speed and more concerned with security [Ref 
38: p. 120]. MD5 makes four passes over each 16-byte block. Fahn stated that MD5 is 
the most often recommended hash algorithm for digital signatures [Ref 37: p. 48]. 

b. Secure Hash Standard (SHS) 

The Secure Hash Standard (SHS) is a hash function proposed by NIST and 
adopted as a U.S. government standard, FIPS PUB 180, to check the integrity of data. It 
is designed for use with the DSS. SHS produces a 160-bit hash value from a variable size 
of input usually less than 2 ^ bits via five passes. The hash algorithm is similar to MD5 
but, as it makes one more pass and produces longer hash value than MD5, it may be more 
secure than MD5. 

5. Encryption in Networks 

As mentioned before, encryption is a powerful tool to provide security services. 
In network applications, encryption can be applied either between two communicating 
hosts or between two applications. The former is link encryption, and the latter is 
end-to-end encryption. Usually, the location of the encryption scheme used in networks 
is well explained with the OSI reference model. In link encry'ption, the encryption occurs 
at layers 1 or 2 in the OSI model. In the end-to-end encry'ption occurs at the highest 
layers. Both methods have their pros and cons; thus, the selection decision depends on 
the situation or networks architecture, which requires encryption. 
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a. Link Encryption 


In link encryption, data is encrypted just before it is placed on the physical 
communications link. Decryption occurs just as the communication enters the receiving 
computer. Encryption protects the message as it is in transit between two computers, but 
the message is in plaintext inside the hosts. Link encryption is invisible to the user or 
even the operating system. Thus, encryption is one service performed by a low-level 
network protocol layer as a hardware function, such as message routing or transmission 
error detection. 

Link encryption is especially appropriate where the transmission line is 
the point of greatest vulnerability. If all hosts on a network are reasonably secure, but the 
communications medium is shared with other users or is not secure, link encryption is an 
easy control to use [Ref 35: p. 376]. 

b. End-to-End Encryption 

End-to-end encryption provides security from one end of a transmission to 
the other. The encryption is performed at a the highest levels of the OSI model (either 
the application layer or presentation layer), and can be applied by a hardware device 
between the user and host computer or software running on the host computer. The 
encryption can be done with software, so that it is easy to apply encryption selectively to 
one application or even to one message within a given application, although it requires 
human intervention [Ref 35: p. 380]. As the message is only exposed by the user who 
has a proper device or software, it can pass any insecure node between two 
communications entity. 

c. Link Encryption vs. End-to-End Encryption 

In link encryption, the communicating hosts and other intermediate hosts 
must have the cryptographic facility to transmit a message, because both the message and 
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other headers (which contain information required to deliver the message to its 
destination) attached to a message are encrypted. Thus, all the hosts should be secure 
enough to prevent any message exposure. By contrast, in end-to-end encryption only 
communications hosts need the cryptographic facility since the intermediate hosts along 
a transmission path do not need to decrypt a message. Therefore, the message can be 
sent through any insecure networks although it can't prevent the passive attack, such as 
traffic analysis or network monitoring. 

The number of required keys is another concern. With link encryption, 
the number of required keys depends on the network architecture; if very few hosts were 
directly connected to a single host, the number of keys would be fairly small, but if each 
node had a link to every other node, then the number of keys would be at most n*(n-l) '2 
where n is the number of nodes. With end-to-end encryption, as the encryption is done 
with user, the number of keys is very large, which is n*(n-J) 2 for n users, not nodes. 
This number increases rapidly as the number of users increases. With the public key 
system, the number of key-pairs (public key and private key) is dramatically reduced to n 
for n users. However, as the public key encryption takes longer than the secret key and 
doesn't provide secrecy and authenticity at the same time, it may cause some overheads 
to solve these disadvantages. 

In summary, link encryption is faster, easier for the user, and uses fewer 
keys. End-to-end encryption is more flexible, can be used selectively, involves the user, 
and can be customized to the application. If a user cannot trust the security provided by 
either link encryption or end-to-end encryption, both forms of encryption can be applied 
within a single network. If both encryptions are reasonably fast, this duplication of 
security will have little negative effect [Ref 36; p. 380]. The applications of security 
service on the current commercial Internet well reflect the basic ideas of these 
approaches; the Secure HyperText Transfer Protocol (SHTTP) for end-to-end encryption, 
the Secure Sockets Layer (SSL) for link encryption, and Terisa Systems for both [Ref 
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39], The details of these approaches are described in the next section as "commercial 
Internet and transaction security." 

C. APPLICATIONS OF DATA ENCRYPTION 

1. Digital Signature 

It is often useful to prove that a message was generated by a particular individual. 
In a networking environment, a message itself is usually not enough to provide the 
author's identity. Since business transactions using networks, such as EC/EDI, are 
increasing, the importance of proving the sender's identity and the legitimacy of a 
message is also increasing. In fact, the lack of secure authentication has been a major 
obstacle in achieving the promise that computers would replace paper [Ref. 37; p. 18]. 

A digital signature is a protocol that produces the same effect as a real signature. 
It is a mark that only the sender can make, but others can easily recognize as belonging to 
the sender. Therefore, digital signatures should be strong against forgery and authentic. 
Pfleeger suggested two more properties that are desirable for digital transactions: not 
alterable and not reusable by others [Ref 35; p. 134]. The efforts to develop a digital 
signature scheme were initiated with conventional cryptography and even without 
encryption techniques, but those approaches were not so successful. However, the use of 
the public key algorithm provides most of the properties required for a digital signature. 
At present, digital signature using public key cryptography with other integrity checking 
algorithms provides an effective way to convert the most essential paper-based 
documents to digital electronic media with authenticity and non-repudiation services. 

a. Direct/Arbitrated Digital Signature 

According to number of parties involved in the use of a digital signature, 
digital signatures can fall into two categories: direct digital signature and arbitrated 
digital signature. The direct digital signature involves only the communicating parties. 
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A digital signature may be formed by encrypting the entire message with the sender's 
private key, or by encrypting a hash value of the message with the sender's private key 
[Ref 36; p. 186], Confidentiality of a message can be provided by further encrypting the 
entire message plus signature with either the receiver's public key or a shared secret key. 
Direct digital signature is convenient and easy to use for internal communications or 
when the domain of communications is relatively small. The validity of this scheme 
depends on the security of the sender's private key, and on mutual trust. 

Arbitrated digital signature involves an arbiter who plays a sensitive and 
crucial role to verify the signatures. With this scheme, every signed message from a 
sender goes first to an arbiter to check the origin and content, then to a receiver with 
additional information that states the message and signature are verified. Depending on 
the level of secrecy of the message contents, an arbiter may verify either a plain message 
with signature or an encrypted message with signature. In general, to use arbitrated 
digital signature, all communicating parties must have a great deal of trust that the 
arbitration mechanism is working properly [Ref 36: p. 187], 

b. Choice of Digital Signature Techniques 

To utilize the advantage of digital signature techniques, communicating 
parties (including arbiters if necessary) should use one technique to verify each other. At 
present, there are two distinguished techniques for digital signature: RSA algorithm and 
DSS. RSA public key algorithm is a de facto industry standard widely accepted by 
businesses. DSS is a U.S. Federal standard, which was published by NIST with the 
intention of royalty-free (no infringement on any patent right) algorithm for public use of 
digital signature. The procedures of digitally signing and verifying functions in these two 
techniques are briefly shown in Figure 7. 

The comparison between these two digital signature techniques suggests 
that RSA algorithm has more advantages than DSS. First, RSA enables key-exchange 
and encryption of messages without using other mechanisms, when DSS requires other 
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mechanisms to provide confidentiality of a message. Actually, key-exchange and 
encryption may be done with a hardware device such as the Fortezza PC card. However, 
individuals and organizations that do not use that device still need to select a secure form 
of key-exchange or encryption mechanisms to achieve additional functions in DSS. 
Second, RSA is faster in signature verification, although DSS is faster in signature 
generation. But, as the actual necessity of digital signature is to verily message 
authenticity, faster signature verification is more widely considered for a characteristic of 
a good digital signature algorithm. 
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The only advantage of DSS is its royalty-free option. However this 
advantage is only available for government use of DSS and for those vendors that deliver 
DSS products to the government [Ref 40: p. 82], Thus, commercial use of DSS should 
pay for the patent right of public key encryption, possessed by Public Key Partners (PKP). 
Although the publication of DSS as a federal standard represents an initiative of the 
government to enable EC/EDI, without the promise of free commercial use of DSS, it 
only gives limited incentives toward a ubiquitous digital signature scheme. 

c. Digital Signature Certificate 

In practice, a digital signature system requires a means for associating pairs 
of public and private keys with the corresponding users. Also, if digital signatures are to 
replace handwritten signatures, there must be a way to bind a user's identity and his/her 
digital signature so that it has the same legal status as handwritten signatures. In fact, 
digital signatures using public key algorithms, hash functions, and encryption are more 
immune to forgery, and have the potential to possess greater legal authority than 
handwritten signatures. 

Since the validity of documents with digital signatures has never been 
challenged in court, their legal status is not yet well-defined. Through such challenges, the 
courts will issue rulings that collectively define which digital signature methods, key sizes, 
and security precautions are acceptable for a digital signature to be legally binding [Ref 
41]. At present, the legality of handwritten signatures is protected by several branches of 
law, such as the statute of Frauds, the Law of Acknowledgments, the Law of Agency, and 
the Uniform Commercial Code (UCC) [Ref 41]. To achieve the same effect of legal 
protection related to signature, Pao suggested the use of an initial handwritten agreement 
defining the procedures and protocols for the utilization of digital signatures between 
senders and receivers [Ref 45: p. 35]. 

To replace handwritten signatures with digital signatures, however, there 
should be an established government policy for handling signature certificates that validate 
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a user's electronic signature. To do this, this policy should define the relationship with 
previous policies, such as security structures in EDI (currently defined by ANSI X12.58 
version 2) or public key certificate (ANSI X.509). Yet, as government initiation of DSS is 
different to industry's use of RSA, the settlement of this bi-directional approaches, and the 
cost of certificating digital signatures are current barriers against digital signature 
certificates. 

2. Secure Mail Systems Using Data Encryption 

In all distributed networking environments, electronic mail (e-mail) is the most 
heavily used network-based application. Actually, it is the only distributed application that 
is widely used across all architectures and vendor platforms [Ref 36: p. 361]. The 
Internet provides a common basis for world-wide mail delivery service, directly or 
indirectly. With the explosively growing reliance on e-mail for every conceivable purpose, 
there grows a demand for secure e-mail systems. The requirements for a secure e-mail 
system include not only the services required by other network applications, but also 
mail-specific services, such as proof of submission, proof of delivery, or message flow 
confidentiality [Ref 38; p. 333]. 

However, the Simple Mail Transfer Protocol (SMTP) supported by TCP/IP 
cannot satisfy all the demands of a secure e-mail system. At present, there are three 
standards related to secure e-mail services, which provide or specify those demands. This 
subsection briefly overviews security functions of those three approaches. 

a. Privaq^ Enhanced Mail (PEM) 

Privacy Enhanced Mail (PEM) was developed by the Internet community 
as a means of adding encryption, source authentication, and integrity protection to 
ordinary text messages [Ref 38: p. 357]. The most common use of PEM is in 
conjunction with SMTP, but it can be used with any electronic mail scheme, including 
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X.400. To support this usage, PEM specifies dual address, one for SMTP, and another 
for X.400. 

Actually, a message in PEM is composed of four types: (1) ordinary, 
unsecured data, (2) integrity-protected, unmodified data, (3) integrity-protected, encoded 
data, and (4) encoded, encrypted, integrity-protected data. These four types of 
sub-message can be encapsulated inside of one another. For encryption, PEM supports an 
RSA-based public key scheme (used for key interchange or key encryption) and two 
variants of DES (used for message encryption). To support public key technology, PEM 
defines a certification hierarchy based on the X.500 naming hierarchy (X.509 certificates 
and CDLs). For integrity protection and authentication, PEM supports RSA digital 
signature scheme with MD2 or MD5. Because PEM expects to handle ordinary text only, 
it has a encoding function to put messages into canonical form before encrypting them, or 
computing message integrity codes, so that the encrypted or signed form will not depend 
on the local formats of the system. [Ref 38: p. 358 - 394] 

b. Pretty Good Privacy (PGP) 

In Pretty Good Privacy (PGP), mail message is only one variant of files, 
because PGP performs encryption and integrity protection based on files. Therefore, it is 
possible to process mail message as an ordinary file, then send it with other mail systems. 
However, for user convenience, a later version of PGP enables users to integrate PGP into 
their mail systems [Ref 38: p. 400]. 

The cryptographic functions of PGP provides three types of message, 
authentication only, confidentiality only, and both. For authentication, PGP supports the 
RSA digital signature scheme with MD5. The difference between PEM and PGP in 
authentication function is that PGP delegates the management of public key certificates 
to the user, while PEM supports a rigid hierarchy of public key certificates in X.500. 
Thus, PGP provides three fields for doing this: the key legitimacy field, signature trust 
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field, and owner trust field [Ref. 36: p. 377], For confidentiality, PGP supports IDEA for 
message encryption, and RSA for the IDEA session key encryption. 

PGP canonicalizes only text files, and retains binary files as their own 
formats. An additional function of PGP is data compression. As a default, PGP 
compresses the message after applying the signature but before encryption [Ref 36: p. 
366]. This has the benefit of not only saving space for both e-mail transmission and for 
file storage, but also providing additional strength to the cryptographic algorithm. 

a X.400 

X.400 is one of the CCITT's standards that describes the system model and 
Elements of Service of the Message Handling System (MHS) and Services. Rather than 
providing complete specifications of a system as PGP or PEM do, it only gives a 
framework for an implementation so that the implementor might decide specific types of 
system to fill "object identifier" that is remained as blank for interoperability. For this 
reason, X.400 does not specify any encryption algorithm (except RSA in X.509). The 
design of X.400 is reminiscent of post office mail, including features equivalent to certified 
mail and returned receipt mail. Interpersonal mail, defined in X.420, and EDI, defined in 
X.435, are certain the types of message that X.400 might carry [Ref 38: p.413 - 415]. 

An X.400 message consists of two parts, envelope and content. The 
former is control information, and the latter consists of a header followed by a sequence of 
body parts. The security features of X.400 are provided by fields that are part of the 
envelope. All the security related fields in X.400 are optional. Parts of those security 
related fields within the envelope are per-message security fields that define key 
certificates, message confidentiality, origin authentication, and other secure message 
handling functions. They also define six levels of message security classification from 
unmarked to top secret. However, the details of dealing with these different class of 
message are not specified. One of the security fields mentioned in X.420 is encrypted 
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body parts. Yet, the parameters of such a body part and the encryption technique are not 
specified, either. [Ref 38: p. 417 - 424] 

As X.400 security has not been really deployed, Kaufman et al. suggested 
that a perfectly reasonable method of obtaining mail security with X.400 is to use the 
PEM body part, and use PEM for encryption, integrity protection, and source 
authentication [Ref 38: p. 419] . This approach is simple to implement but PEM is only 
for text and there might be an extreme overhead when encoding multi-media (such as 
video, audio, or facsimile) messages into text format. 

3. Commercial Internet and Transaction Security 

While the proliferation of the Internet enables easy access to information 
distributed across thousands of computers, businesses are also tring to find a way to 
convert their business processes from paper transactions to digital, on-line transactions via 
Electronic Commerce/Electronic Data Interchange (EC/EDI). But security risks are still 
the major concern threatening their actual movement toward EC/EDI. Many transactions 
require the ability to protect confidential information, authenticate the source of 
communications, ensure the integrity of message content, and verify the transmission and 
receipt of a message. 

The term "transaction security" refers to the networks services that satisfy all these 
requirements. At present, two different approaches are initiated for the transaction 
security. These are Secure HyperText Transfer Protocol (SHTTP) and Secure Sockets 
Layer (SSL) Protocol. SHTTP marks individual documents as private or signed at the 
application layer of OSI model, while SSL mandates the channel of communication 
between two parties as private and authenticated by encrypting the documents at the top 
of the transport layer. Since these approaches were initiated separately with different 
perspectives and still compete with each other for the final approval as a common security 
standard, there may be a non-interoperability problem between SHTTP and SSL. Rather 
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than selecting one approach, the Terisa system [Ref. 39] suggested a new approach 
adopting those two approach altogether. 

CL Secure HTTP (SHTTP) 

HyperText Transfer Protocol (HTTP) is the internal communications 
protocol of the World-Wide Web. Secure HTTP (SHTTP) is security enhanced version of 
HTTP that was developed by Enterprise Integrated Technologies (EIT) Inc., and is now 
available to the Internet community as a non-proprietary specification [Ref 40]. It 
provides secure communication mechanisms between an HTTP client-server pair in order 
to enable spontaneous commercial transactions for a wide range of applications. The 
protocol emphasizes maximum flexibility in the choice of key management mechanisms, 
security policies and cryptographic algorithms by supporting option negotiation* between 
parties for each transaction. 

SHTTP is one example of end-to-end encryption. Security functions are 
located at the highest level of the OSI model, the application layer. The message 
protection may be provided by signature, authentication, and encryption. For digital 
signature, it supports both RSA and DSA schemes. For message integrity and user 
authenticity, it supports the Message Authentication Code (MAC) via manual arrangement 
or Kerberos. For encryption, it supports symmetric key algorithms, such as DES or RC2, 
with various key-exchange mechanisms, including the public key scheme. The major 
cryptographic message format standards supported by SHTTP are PKCS-7, PEM, and 
PGP, although the format standards are not limited to those three standards [Ref 42]. 
After all, the message block consists mainly of four portions; the main SHTTP header, 
encapsulated non-negotiation header, encapsulated negotiation header, and privacy 
enhanced original message. 


* Negotiation is a method to express the requirements and preferences regarding 
what cryptographic enhancements will be permitted/required between two communicating 
parties [Ref 42; p. 11]. 
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b. Secure Sockets Layer (SSL) Protocol 


The Secure Sockets Layer (SSL) Protocol, developed by Netscape 
Communications Corp., is a security-enhanced abstraction of sockets that provides 
transaction security at the link or transport level [Ref 39]. Thus, it allows client-server 
applications to communicate in a way that precludes eavesdropping. With SSL, security 
properties are attached to the link or channel of communication between two parties, not 
the documents themselves. 

To provide communications channel security, SSL Protocol uses secret key 
cryptography for data encryption (e.g., DES or RC4’), public key cryptography for 
authentication (eg., RSA), hash functions for data integrity (e.g., MD2 or MD5). 
Actually, SSL Protocol is composed of two protocols: the SSL Record Protocol and the 
SSL Handshake Protocol. The former is used for encapsulation of all transmitted and 
received data, including the SSL Handshake Protocol, in records. The record is a certain 
unit of length composed of a header portion and data portion. SSL Handshake Protocol is 
a series of phases used to establish security parameters negotiated by client and server 
application [Ref 43]. The main advantage of SSL Protocol is that it is application 
protocol independent, thus, any higher-level application protocol can layer on top of the 
SSL protocol transparently. Currently, Netscape Communications Corp. introduced 
another protocol (Secure Courier), which is based on SSL, for transmitting financial data 
over the commercial Internet based on SSL. 

c. Summary 

In summary, SHTTP has the capability to provide comprehensive security 
in a flexible manner, but the service is limited to the Web-specific applications. SSL is a 
more generic security protocol, but it can support any applications using TCP/IP. 

^ The export version of SSL uses 40-bit RC4, where as U.S. version uses 128-bit 
RC4. The 40-bit RC4 was broken by brute force attack in August 1995, thus, there is a 
bit wonder about the security feature of export version of SSL. 
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Although these two emerging approaches utilize a variety of industrial standards and 
protocols, such as HTTP, TCP/EP and RSA public key cryptography, they are unable to 
communicate with each other. To allow the businesses to take advantage of the strength 
of both protocols, the Terisa Systems, a joint venture company by Enterprise Integration 
Technologies and RSA Data Security Inc., provides the unified approach by adopting 
those two different protocols at one package. However, it may be a piggybacking 
approach for transaction security and maybe required only by a big organization that 
actually needs a strong interoperability between SHTTP and SSL. 

The decision to select the most beneficial protocol for EC/EDI data 
transaction among these three approaches is not easy. To select a proper tool, one should 
consider not only requirements for data security and current communications architecture, 
but also the direction of international trends for security standards. 

D. FIREWALL/SECURITY GATEWAYS 

1. Introduction 

A firewall is any one of several ways of protecting an internal network fi’om other 
untrusted networks by filtering packets according to various criteria, usually based on the 
organization's network security policy. Security Gateway is just another name for a 
firewall. The main purpose of a firewall is to prevent unauthorized users from accessing 
computing resources on a private network, and often to prevent urmoticed and 
unauthorized export of proprietary information. In the latter case, the export of 
information is usually not considered important, because the internal user might have more 
convenient ways, such as floppy diskettes or magnetic tapes, to export those proprietary 
information rather than using networks. 

The necessity of a firewall comes from two reasons; a growing use of global 
untrusted networks, such as the Internet, and a lack of security features in the design of 
organization's networks and network operating systems. The Actual mechanisms of a 


73 



firewall are mainly divided into two categories; blocking traffic and permitting traffic. In 
configuring a firewall, these mechanisms represent the organizational policy over existing 
or anticipated levels of threat. If security is more important than anything else, the firewall 
would be designed to block everything except minimum network traffic that comes from 
known, trusted networks of well known applications forms such as e-mail. 

The location of a firewall should be carefully analyzed so that it examines and 
evaluates all traffic passing through it, without exception. If there are more than one 
connection points to outside networks, several firewalls will be required, or the inside 
network may he modified to permit only one connection point to the outside. However, 
to avoid being a bottleneck of networking, the firewall should have enough capacity to 
control traffic. The component of a firewall system can be a router, a personal computer, 
a host computer, or a combination of these. 

2. Firewall Components 
a. Packet Filter 

Packet filters can provide a cheap and useful level of gateway security. It 
is the simplest form of a firewall, and it selectively discards packets based on configuration 
rules. IP packet filtering is usually done with a router designed for filtering packets as 
they pass between the router's interfaces. A packet filtering router usually can filter IP 
packets based on four fields: source IP address, destination IP address, TCP/UDP source 
port, and TCP/UDP destination port [Ref 44; p. 24]. A specially designed host computer 
can also perform packet filtering with additional functions of traffic monitoring and 
auditing. Filtering can be used in a variety of way to block connections from or to specific 
hosts or networks, and to block connections to specific ports, depending on the capability 
of filtering software. 

Packet filtering has a number of weaknesses. IP address based filtering 
does not give any protection against address spoofing attack. The filtering rules are 
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complex to specify and, usually, no testing facility exists for verifying the correctness of 
the rules. Some network services (such as RPC service using UDP) randomly assign port 
numbers so that it is hard to block unfixed port numbers with a fixed rule set of packet 
filters. Undetected errors in filtering software and holes in rule set may exist until a 
break-in has occurred*. As packet filters may permit direct communication between 
multiple hosts on the private network, and multiple hosts on the outside networks, they 
do not provide users with confidence in their correctness and hence their safety. 
However, packet filters are a useful tool on which many advanced gateway designs rely 
[Ref 45; p. 77]. 

b. Application-Level Gateway 

An application-level gateway uses a special-purpose code for each desired 
network application, rather than using a general-purpose mechanism to allow many 
different kinds of traffic to flow. It is far more secure than any of the alternatives. [Ref 
45: p. 75]. Such a special-purpose code is referred to as a proxy service, and handles 
packets between Application Layer and Transport Layer of the TCP/IP protocol stack. 

The proxy service intercepts the service request packets, which are passed 
through a routing device, and go up through each layer of the TCP/IP protocol suite until 
the Application Layer, then checks its table, and denies or grants access to the service, 
based on the source's Internet address and the service being requested. If the service is 
denied, the packet is dropped, the event logged, and nothing further is done. If the 
service is granted, the event is logged, and the packets are passed on to the server, which 
provides the requested application [Ref 46; p, 23 - 24]. 

An application-level gateway may have several proxy services designed 
for FTP, SMTP, TELNET, DNS, or NFS. Compared to pure packet filters, the main 
advantage of application-level gateways is the reduced work of packet filtering. As each 

* Cheswick and Bellovin presented two examples for this; CERT Advisory 
CA-92:20 and CA-93:07 [Ref 46: p.75]. 
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proxy service can deal with one type of application-specific packets, the filtering rule set 
is less complex, and will not affect other resources in the private network. Also, some 
proxy services can provide a protocol filtering service to avoid harmful requests of 
service (such as the "put" command in FTP connections) [Ref 44: p. 30], 

The principle disadvantage of the application-level gateway is the need for 
a specialized user program or variant user interface for most services provided [Ref 45; 
p. 76], Thus, in general, the most important or most popular services can be supported in 
conjunction with the other gateway designs. 

c. Circuit-Level Gateway 

A circuit-level gateway relays TCP connections but does no extra 
processing or filtering of the protocol. It is sometimes included under the category of the 
application-level gateway [Ref 45: p. 31]. When the connection between the source and 
destination is established, the firewall simply passes bytes between the systems as a wire 
does. In general, it is designed to allow open connection to a trusted host located outside 
of the private network, with specially assigned ports. 

3. Applications of Firewall Design 
a. Packet Filtering Firewall 

The packet filtering firewall that uses screening routers is the most 
common and easiest to employ for small, uncomplicated sites, since it permits fairly free 
access to WAN from any point within the private network. However, as mentioned in the 
previous subsection, there are many problems in a pure packet filtering router. Thus, the 
firewall design using only a screening router is not enough to provide required security 
for the private network. 
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b. Dual-Homed Gateway Firewall 


The dual-homed gateway consists of a host system (sometimes called a 
bastion host) with two network interfaces, and with the host's IP forwarding capability 
disabled. Unlike the packet filtering firewall, the dual-homed gateway is a complete 
block to IP traffic between WAN and the protected private network. Both the private 
network hosts and outside hosts can talk only to the gateway. The connection between 
the private network and WAN is controlled by proxy services residing on the gateway. 
Thus, the gateway denies all services unless they are specifically permitted by proxy 
services. The disadvantage of the dual-homed gateway firewall is its inflexibility to other 
services that are not provided by proxy services [Ref 45: p. 36]. The other security 
concern of this option is the strength of gateway. Since the gateway provides all 
protection for the private network, any weakness in the gateway may compromise the 
security of the entire private network. 

c. Screened Host Firewall 

The screened host firewall is a more flexible firewall than the dual-homed 
gateway firewall, however the flexibility is achieved with some cost to security. It 
combines a packet filtering router with an application gateway that has only one interface 
to either the private network or WAN side. In this configuration, certain trusted services 
may pass through the gateway if the gateway does not have the required proxy service; 
hence, the firewall is more flexible but less secure than the dual-homed gateway option. 
The actual decision regarding construction of this firewall could reflect a mixture of the 
two design policies, the proportions of which depend on how many and what types of 
services are routed directly to the private network [Ref 45: p. 36 - 38]. 
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Figure 8. Applications of Firewall Design 


(L Screened Subnet Firewall 

The screened subnet firewall consists of two routers and an 
application-level gateway. It is a variation of the dual-homed gateway and screened host 
firewalls. In this configuration, there are three portions of networks: the private network, 
screened subnet (sometimes referred to as "DMZ"), and WAN. On the screened subnet. 


78 






the application-level gateway and other network service hosts (such as the FTP server 
and e-mail server) can be located more securely than other firewall options without 
aflfecting the security of the private network. The outer router restricts access from 
outside to specific systems on the screened subnet. The inner router passes traffic to and 
from systems on the screened subnet. These two routers are used to direct traffic to 
specific systems, eliminating the need for the gateway to be dual-homed. Consequently, 
this firewall configuration may be more appropriate for sites with large amounts of 
traffic, or sites that need very high-speed traffic. Also, each component of the firewall 
needs to implement only a specific task; thus, the systems are less complex to configure. 
However, in terms of security, it is less desirable than the dual-homed gateway because it 
might be possible to allow certain trusted services from outside to private network [Ref. 
45: p.40]. 

4. Trusted Guard Gateway (TGG) 

In the CALS telecommunications security plan, Doby reported the necessity of 
the Trusted Guard Gateway (TGG), which was intended to provide security and 
interoperability among DDN segments (ARPANET, MILNET, DISNET) [Ref. 2: p. 22 - 
24]. For security, the role of TGG is to provide limited but secure communications 
between the communities whether operating at different levels of trust or at different 
levels of security. Figure 9 shows three different types of TGG: a MELNET/DISNET 
TGG, an ARPANET/MILNET TGG, and a closed-community/open-community TGG. 

The MILNET/DISNET TGG is a gateway that supports unclassified 
communications between two different security levels of network. It requires more 
secure and intelligent capability than general purpose firewalls, since it involves security 
classification upgrading or downgrading when the information is classified. Also, it 
requires an end-to-end encryption device, such as BLACKER, to avoid any possible 
classified information exposure [Ref 2: p. 2], 


79 




The ARPANET/MILNET TGG was primarily intended for e-mail transfer and 
limits other traffic between two networks that were separated from DDN in 1983. It can 
be considered as a firewall using an application-level gateway that provides limited 
network services. Although the information may not classified in MILNET or 
Commercial networks, the design criteria of the gateway should represent the security 
policy of related networks to provide required protection for sensitive information. 

The third type of TGG was intended to limit communications between open and 
closed communities which were included in a same level of network. The reason of this 
consideration came from the lack of security certification of host computers, which was 
intended to the C2 level or better. The non-certified hosts would be grouped as the closed 
community and only have limited access to other side of community through TGG. 
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The three types of TGKj shows a iiiodel of actual firewall design specifically 
required to the military subscribing host computers. As CALS communications require 
interconnection between industry networks and military networks, the firewall design 
should be considered one of the important resources to provide proper protection against 
any possible information exposure. 

5. Firewall and Security Policy 

Firewalls are a powerful tool for network security. However, it should be 
considered that firewalls also have their limitation. Though firewalls are very strong 
defense against attacks at a low level of the protocol stack, in contrast, firewalls provide 
almost no protection against problems with higher level protocols [Ref 45; p. 82]. 
Firewalls cannot protect against attacks that do not go through the firewall. As attacks 
against private networks always seek the most vulnerable point, any open connection 
which is not protected by firewalls makes the elaborate efforts of constructing firewalls all 
for naught. Firewalls cannot protect against a data-driven attack - attacks in which 
something is mailed or copied to an internal host where it is then executed®. Even though 
known contexts of data-driven attacks are scanned during it passes through the firewall, 
still there is possibility of unknown types of attack. 

Cheswick described the firewall as, at best, a convenient single place to apply a 
corrective filter [Ref 45; p. 83]. However, the realistic firewall policies that reflect the 
level of security in the entire network can provide adequate protection for the 
non-classified information. Even more, combined with encryption tool, it might be 
applicable high level secure data delivery. 

The users act very important role in the firewall configuration. Misuse or flouting 
of the security policy can easily bring security holes on the entire networks. It is obvious 
that firewall cannot replace security-consciousness of users on the private network. Thus, 


The Internet Worm is one of the notorious example of this type of attack. 
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the users on the network should be continuously aware of the firewall policies to achieve 
overall security of their systems. 
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V. SECURITY MANAGEMENT OF CALS 
TELECOMMUNICATIONS 

A. CALS SECUMTY REQUIREMENT 


When CALS automates and integrates digital, processable information using a 
shared database, it should be implemented with a proper means to protect this shared 
data environment from unauthorized access, use, or alteration throughout the life-cycle of 
a weapon system. To protect and assure the integrity of CALS data, DoD presented six 
interrelated security disciplines based on DoDD 5200.28, Security Requirements for 
Automated Information systems [Ref 13: p.204]: 

• Communications Security (COMSEC); The protection resulting from the 
application of transmission security, crypto security and emission security 
measures to telecommunications, and from the application of physical security 
measures to COMSEC information. 

• Computer Security (COMPUSEC); The totality of security safeguards needed 
to provide an acceptable level of protection for Automated Data Processing 
(ADP) systems and the sensitive data processed. 

• Physical Security: The physical measures that are designed to prevent 
unauthorized access to equipment, facilities, material, and documents, and to 
safeguard against espionage, sabotage, damage, and theft. 

• Personal Security: The measures whereby the trustworthiness and suitability of 
personnel are verified for positions of trust based on information regarding their 
loyalty, character, emotional stability, and reliability. 

• Information Security (INFOSEC): The measures and administrative procedures 
for identifying, controlling, and protecting against unauthorized disclosure of 
classified information or sensitive unclassified information. 

• Operations Security (OPSEC): The protection of operations resulting from the 
identification and subsequent elimination or control of intelligence indicators 
susceptible to compromise. 
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To satisfy all of these security requirements is not an easy task. It may add 
further costs to the CALS implementation. However, it is very important to assure the 
data protection and integrity for the future of fully integrated information systems. Were 
it not a proper protection mechanism, the potential participants of the integrated 
information system might fear the word "integration" or "data sharing." Thus, the 
cooperation between government and industry for establishing adequate security 
protection to an integrated information system should exist, in addition to the integration 
efforts. 

This chapter will analyze such a mechanism to satisfy security requirements for 
CALS telecommunications. Security is only as good as its weakest point. Therefore, the 
security management of CALS telecommunications should concentrate on identifying the 
weakest point of overall security, and on providing an adequate protection mechanism for 
that point. 

B. SECURITY POLICIES AND STANDARDS RELEVANT TO CALS 

1. Overview 

The Automated Interchange of Technical Information (MIL-STD-1840) and 
CITIS (MIL-STD-974) are a good starting point to assess the requirements for the secure 
CALS telecommunications plan. Usually, MIL-STD-1840 and CITIS are considered 
mutually exclusive concepts dealing with delivery methods of CALS data in a physical 
form or an electronic one. In fact, those two standards are complementary rather than 
mutually exclusive. Because MIL-STD-1840 was designed to support a digital data 
delivery, the standardized header records specified in the standard are very important for 
CITlS's function of data configuration management, including data dictionary and data 
directory services. Security features in these two standards are shown below: 
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a. MIL-STD-1840B 


The current version of MIL-STD-1840 defines the formats, standardized 
header records, and the contents of the files used for the exchange of data as well as 
requirements for labeling, protection, packaging, and the making of media during 
shipment. According to MIL-STD-1840B [Ref 47], each transfer package may consist of 
one or more transfer sets, which include multiple transfer units. Each transfer unit has a 
unit declaration file, which has 17 fixed length records of 128 bytes each, and several 
unit data files. Two security related records in the unit declaration file are: 

• Title Security Label (ttlcls): A character string stating the 
security/sensitivity level or other restrictions on the title of the 
document. 

• Document Sensitivity Label (doccls): A character string stating the 
highest security/sensitivity level or other restrictions on any file in the 
transfer unit. 

A unit data file has fixed-length head records describing all the 
characteristics of a data file. It is fixed length, but the actual length may depend on the 
data file type specified by a contract. Among various head records, there are two security 
related records: 


• Source System Document Identifier (srcdocid): A character string used 
by the source system to uniquely identify the document to which this 
file belongs, comprises, or applies. Position 57, data rights, and 
position 61, security classification, are two important elements. 

♦ Data File Security Level (doccls): Character string stating the 
security/sensitivity level or other restrictions on the data file. 

As many of the standards and specifications required or referenced by 
MIL-STD-1840B are evolving significantly due to rapidly advancing technologies, these 
will have to be implemented further in a future revision of this standard [Ref 8: p. 12-9]. 
The candidates of these standards and specifications are lETM, EC/EDI, PDES, 
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telecommunication standards (X.400, X.435, X.500), and methods of compression and 
encryption. 


b. Contractor Integrated Technical Information Service (CITIS) 

The CITIS (MIL-STD-974) was developed to provide the government 
with electronic transfer of, and access to contractor-maintained data and Government 
Furnished Information (GFI), as specified by the contract. The capability of electronic 
transmission of data using CITIS is not limited to the government and its contractors. It 
also can be used for electronic data transmission among business partners in usual 
business contracts. The present version of CITIS defines the role of CITIS as 
information service, data configuration management, CITIS security, data item index, 
and other functions [Ref 18: p. 7]. 

There are two functions in CITIS: core and tailorable. The core functions 
deal with basic functional requirements'” required for on-line delivery of data instances. 
Tailorable CITIS functions are more complicated than core functions, because those 
functions deal with a directory or dictionary of data items to support application 
softwares, packages of user selected data items, or queries. Tailorable functions require 
a reasonable telecommunications capacity to enable on-line data transfer between the 
government site and the contractor; thus, these functions may be limited until the 
Defense Information Infrastructure is modernized. 

As CITIS uses networks connecting CITIS sites, all the security issues 
mentioned in Chapter IV are inherent in CITIS. Also, as information provided by CITIS 
may include a combination of differently classified data, each data item in each different 
level of classification should be properly marked for proper access control. Examples of 
parameters that define the access rule set include: information type; information access 
strategy; data status level; type of access; classification and sensitive data limitations; 

The functional requirements include acknowledgment of delivery of data 
instances, approval of data instances and logging, comment on data, receive, search, 
store, and view function. 
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distribution limitations; maximum allowable number of unsuccessful or improper access 
attempts; and the authorized user's security clearance, organization, location, CITIS 
read/write authorizations, and access profile [Ref 18: p. 14], 

CITIS can use data formats specified in MIL-STD-1840 as a data 
exchange standard. However, both security reasons and the requirements to support 
application softwares (which will be used in the future CALS environment) suggest that 
the header format of data elements specified by MIL-STD-1840 may not be sufficient for 
CITIS's use. Since MIL-STD-1840B specifies off-line delivery methods of CALS data as 
a package, there may be some redundancy of data when users store separately delivered 
packages in their own databases. As CITIS promises delivery of data in terms of data 
elements, there should be more specific information in the head of each data element 
related to the data dictionary/directory service. Thus, to adapt CALS as a national 
strategy to develop information technology, earlier consideration of security-specific 
fields and transmission-specific fields in data element headers will reduce further 
revising efforts. 

2. Trusted Computer System Evaluation Criteria (TCSEC) 

Trusted Computer System Evaluation Criteria (TCSEC) is one of the most widely 
acclaimed documents for Trusted Computing Base (TCB). Published by DoD in 1983 
and revised in 1985, TCSEC provides authoritative guidance, measurement, and 
acquisition criteria for evaluating the security features of computer systems. For 
guidance, it provides a standard to manufacturers as to what security features to build 
into their new and planned commercial products in order to satisfy trust requirements for 
sensitive applications. For measurement, it provides users with a metric to evaluate the 
degree of trust that can be placed in computer systems for the secure processing of 
classified and other sensitive information. For acquisition, it provides a basis for 
specifying security requirements in acquisition specifications [Ref 48: p. 2]. 


* 
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a. Fundamental Computer Security Requirements 


TCSEC defines secure systems as those systems that control, through use 
of specific security features, access to information such that only properly authorized 
individuals, or processes operating on their behalf, will have access to read, \vrite, create, 
or delete information. From this definition, TCSEC derives six fundamental 
requirements: 

• Security Policy: Given identified subjects and objects", there must be a 
set of rules that are used by the system to determine whether a given 
subject can be permitted access to a specific object. This policy further 
specifies mandatory security control" and discretionary security 
control 

• Marking: Access control labels must be associated with an object. This 
capacity, together with mandatory security policy, ensures that 
clearances associated with users and objects accurately reflect the 
security levels of these subjects and objects. 

• Identification: Each access to information must be mediated, based on 
who is accessing the information, and what classes of information they 
are authorized to deal with. 


An object is a passive entity that contains or receives information, such as 
records, files, directories, and programs. A subject is an active entity, generally in the 
form of a person, process, or device that causes information to flow among objects, or 
changes the system state [Ref 48: p. 116]. 

" Mandatory security control enforces a system by a set of rules for controlling 
access based directly on a comparison of the individual's clearance or authorization for 
the information and the classification or sensitivity designation of the information, and 
indirectly on considerations of physical and other environmental factors of control. 

" The term discretionary security control refers to a system's ability to control 
information on an individual basis. In the discretionary security enforced system, even 
though an individual has formal clearance for access to specific information, each 
individual's access must be based on a demonstrated "need-to-know" [Ref 48: p. 74 -75], 
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• Accountability: The occurrence of security-relevant events in an audit 
log must be kept and protected selectively so that actions affecting 
security can be traced to the responsible party. 

• Assurance: The computer system must contain hardware/software 
mechanisms that can be independently evaluated to provide sufficient 
assurance that the system enforces the requirements shown above. 

• Continuous Protection: The requirements must be continuously 
protected against tampering and/or unauthorized changes. 

b. Divisions of Security Protection 


TCSEC specifies four hierarchical divisions of security protection criteria: 
D, C, B, and A. Division D is reserved for systems that have been evaluated but fail to 
meet those security requirements. Division C has two classes: Cl and C2, which require 
discretionary access control protection. Division B has three classes: Bl, B2, and B3, 
which require support for sensitive labels. Division A has only one class, Al, which 
requires additional assurance through formal verification methods. The classes and their 
security requirements are shown in Table 7. 

• Cl (Discretionary Security Protection): This class nominally satisfies 
the discretionary security requirements by providing separation of users 
and data. It incorporates some form of credible controls capable of 
enforcing access limitations on an individual basis. The class Cl 
environment is expected to be one of cooperating users processing data 
at the same level of sensitivity. 

• C2 (Controlled Access Protection): This class enforces a more finely 
grained discretionary access control than Cl class, making users 
individually accountable for their actions through login procedures, 
auditing of security- relevant events, and resource isolation. 

• Bl (Labeled Security Protection): In addition to C2 requirements, this 
class enforces the preparation of informal statements of security policy 
models, data labeling, and mandatory access control over named 
subjects and objects. 
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Table 7. TCSEC Summary Chart 
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• B2 (Structured Protection); This class enforces the use of formal 
security policy models that require discretionary and mandatory access 
control enforcement used in B1 class to be extended to all subjects and 
objects in the Automated Data Processing (ADP) system. Compared to 
B1 class, it has many more security features to assure the security of 
systems. 

• B3 (Security Domain): This class must satisfy the reference monitor 
requirements that mediate all accesses of subjects to objects; it must be 
tamper-proof and small enough to be subjected to analysis and test. 

• A1 (Verified Design): This class is functionally equivalent to B3. The 
distinguishing feature of this class is the analysis derived from formal 
design specification and verification techniques, and the resulting high 
degree of assurance that the TCB is correctly implemented. 

c. Security Modes of Operation 

When the systems evaluated by TCSEC are used in an actual operation, 
the security modes can be defined by a manner in which the access requirements for user 
clearance level and need-to-know''* are implemented in the Automated Information 
System (AIS). Security modes are authorized variations in security environments and 
methods of operating trusted systems that handle classified information [Ref 50: p. 
8-2-1]. To provide adequate protection of classified information while allowing users to 
access proper information, these modes may be tailored by the organization. Current 
security operating modes defined by NCSC are shown below [Ref 51: p. 9 -10]: 

• Dedicated Security Mode: The dedicated security mode is specifically 
and exclusively dedicated to and controlled for the processing of one 
particular type or classification of information, either for full-time 
operation or for a specified period of time. 

• System High Mode: The system high mode is defined by 
software/hardware trusted to provide only need-to-know protection 

Need-to-know is defined as a determination made by a possessor of classified 
information that a prospective recipient has a requirement for access to, knowledge of, or 
possession of the classified information in order to accomplish lawful and authorized 
government purposes. [Ref 50: p. 1-9] 
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between users. In this mode, the entire system must operate with 
security measures commensurate with the highest classification and 
sensitivity of the information being processed and/or stored. All system 
users in this environment must possess clearances and authorizations for 
all information contained in the system. All system output must be 
clearly marked with the highest classification until the information has 
been reviewed manually by an authorized individual to ensure 
appropriate classifications. 

• Partitioned Security Mode; In this mode of operation, all users have 
clearance but not necessarily formal access approval and need-to-know 
for all information contained in the system. This means that some users 
may not have need-to-know and formal access approval for all data 
processed by the AIS system. 

• Compartmented Security Mode: The compartmented security mode is a 
mode of operation in which each user has a valid clearance for the most 
restricted intelligence information processed in the AIS. Each user also 
has forma! access approval, a valid need-to-know, and a signed 
nondisclosure agreement for that intelligence information to which the 
user is to have access. 

• Multi-Level Security Mode; In this mode, not all users have a clearance 
or formal access approval for all data handled by the AIS. The 
components used in this mode must have the technical capability to 
control access to information based on need-to-know, formal access 
approval, and sensitivity level of the data in the system. 

3. Trusted Network Interpretation (TNI) of the TCSEC 


As a network involves many systems that often have various security levels and 
modes, there is a necessity to control the network either component by component or as a 
entire system. The Trusted Network Interpretation (TNI) and Trusted Network 
Interpretation Environments Guideline (TNIEG) are an effort of NCSC to interpret the 
TCSEC for networks. The TNI contains all of the criteria in the TCSEC, and adds 
interpretation and rationale to applying trust technology to network systems. It focuses 
on policy and assurance features necessary to achieve a certain level of security 
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accreditation. The TNDEG provides guidance for the use of the TNI by identifying the 
minimum security protection required in different environments [Ref 52: p. 1], 

a. Two Network Views 

The TNI distinguishes two alternative views for accreditation and 
evaluation purposes; as a single unified system or as an interconnection of two or more 
independently accredited automated information systems. 

In the first perspective, a network is regarded as an instance of a single 
trusted system. A more accurate view is when some of its AIS subsystems are so 
specialized or dependent on other subsystems of the network for security support that 
individual accreditation of such subsystems is not possible or meaningful with respect to 
secure network operation. In order to be accredited, the unified system should have a 
coherent network architecture and design, and it should be developed with an attention to 
security requirements, mechanism, and assurances commensurate with the range of 
sensitivity of information for which it is to be accredited [Ref 52: p. 10]. Examples of 
"single trusted systems" include packet-switched networks, end-to-end encryption 
systems, application level networks, and local area networks [Ref 53: p. xv]. 

Interconnected, accredited AIS consists of multiple systems that have been 
independently rated and accredited to process sensitive information at a single level, or 
over a range of levels. Because of the complex structure of a network requiring 
accreditation rules for connection components, it may not be practical to evaluate such a 
network using this interpretation, or to assign it a trusted system rating [Ref 53: p. xiiij. 
However, when a unified system view is not appropriate to accredit a certain network, 
this view would be used with careful consideration. Appendix C of the TNI explains the 
rules and situations required to evaluate a network with this view. 
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b. Network Security Architecture and Design (NSAD) 


The Network Security Architecture and Design (NSAD) shows how the 
Network Trusted Computing Base (NTCB) is partitioned, and how the trusted system 
requirements are met. NSAD results from a series of tradeoffs among cost, effectiveness, 
technical risk, mission requirements, and risk management of a network. While the 
architecture of the NSAD may be somewhat abstract, the design should be quite concrete 
by mapping the selected security services to system functional elements. The NSAD for 
a network must address the applicable security-relevant policies, and may incorporate the 
NSADs of its constituent components or subsystems [Ref 52: p. 15]. 

c. Security Requirements for Network 

The TNI divides security requirements of trusted networks into two parts: 
minimum security requirements, which interpret the TCSEC for networks; and 
qualitative evaluation of security services in terms of functionality, strength of 
mechanism, and assurance. Determining the minimum security requirements for a 
network is nearly the same as for a stand-alone system. Additional factors such as 
communications security, distance between devices, number of subsystems, and 
encryption are considered to determine the minimum security requirement. Part two, 
qualitative evaluation of security services are concerned with functionality, strength of 
mechanism, and assurance of those services that are more network-specific (e.g., 
communications integrity, non-repudiation, and network management, etc.) [Ref 53: p. 
163, 177]. 

4. System Security Engineering Program Management Requirements 
(MIL-STD-1785) 

The System Security Engineering (SSE) program defines the role of security 
throughout the life-cycle of the major development and/or upgrade program, which shall 
be established early in the weapon systems acquisition process. The purpose of this 
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program is to: (1) enhance the operational readiness and mission success of the defense 
resource; (2) identify and reduce potential vulnerabilities to security threats; (3) provide 
management information essential to system security planning and; (4) minimize its own 
impact on overall program cost and schedule [Ref 54: p. 7]. The requirements of the 
SSE program is divided into four phases, the same as the acquisition phases. The detail 
requirements presented by the DoD are shown in Table 8 [Ref. 54: p. 8 -14]. 

Most of these tasks are fulfilled by contractors with the government's 
contract-specific inputs, such as the classification requirement for a weapon system. To 
achieve a defined security level during the entire acquisition phases, the government 
should actively participate in the testing and validation of those tasks. 

5. Industry Security Manual for Safeguarding Classified Information 
(DoD 5220.22-M) 

The Industry Security Manual provides contractors with the provisions of the 
government's information security program that are necessary for safeguarding classified 
information entrusted to contractors who have been selected to perform on classified 
contracts. Issued under the authority of DoD Directive 5220.22, "DoD Industry Security 
Program," the manual establishes the minimum requirements for safeguarding the 
classified information to which contractors and their subcontractors have access or 
possession. The range of this classified information also covers classified foreign 
government information that is furnished to U.S. contractors. [Ref 49: p. 1-1-2] 

Rather than MlL-STD-1785, which provides more specific security requirements 
for the phases of weapon system contracts, the purpose of this manual is to provide 
uniform security requirements to trusted contractors. Examples include security 
clearances of users, security training and briefings, information classification, 
safeguarding classified information, and secure automated information systems 
operation. It reflects an effort of the DoD to demonstrate how information handling 
systems are securely configured or managed, and how information is securely handled by 
industry. 
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Table 8. Task Requirements of SSE Program 


Phase 1: Concept Exploration Phase 


Goal 

Identification of a broad range of security criteria and concepts which satisfy 
operational conditions and mission requirements. 

Task 

Requirements 

• System Security Management Plan (SSMP) 

• Threat Definition and Analysis 

• Preliminary System Security Concept (PSSC) 

• Security Requirements Definition 

• Technology Assessments and Cost Studies 

• Logistic Support 

• Security Training Requirements 

• Reliability and Maintainability Program (R&M) 

• Preliminary Security Vulnerability Analysis 

• Security Classification Requirements 

[|phase II : Demonstration & Validation Phase 


Goal 

Translation of qualitative security criteria (developed during the concept 
Exploration Phase) into quantitative security criteria for specifications that can be 
used during the next phase. 

Task 

Requirements 

• Adversary Mission Analysis 

• Updated and expanded PSSC 

• Review of Security Regulatory Requirements 

• Security Vulnerability Analysis 

• Security System Trade-off Analysis 

• System and Subsystem Specification 

• Manpower Impact Assessments 

||phase III: Full-Scale Development Phase | 


Goal 

Development of the hardware, firmware, and software components of the 
pre-production prototype system according to system specification. Verification 
of compliance with the specification requirements supported by engineering 
development tests, Qualification of security subsystems, and Documentation of 
the information required for the next phase. 

Task 

Requirements 

• System Security Requirements Definition 

• Expanded SSMP 

• Subsystem and Interface Specifications 

• System Security Design 

• Subsystem Verification Analysis 

• Subsystem and System Response Analysis 

||phase IV : Production & Deployment Phase 


Goal 

To ensure that defined security requirements are met in the operational system. 


Task 

Requirements 

• Acceptance Testing 

• Training on Security Systems 

• Program Management Responsibility Transfer (PMRT) Support 

• Product Security 
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C. SECURITY CONSIDERATIONS FOR CALS 


When the communications plan for implementing CALS is designed, there are 
very critical security considerations that should be examined prior to the actual plan. 
Some of these considerations are related to security policies concerning data protection, 
and others deal with securing methods and technologies for information. This section 
addresses some of the security considerations that emerged from the U.S. CALS 
implementation history or from other security domain technologies. 

1. Security Classification 

Combined with user clearances, the classification of data plays a very important 
role in determining the level of security protection for both single computer systems and 
networked systems. Actually, the security mode of operation and the requirement of 
adequate trusted systems discussed in the previous section are evaluated by calculating 
the risks of disclosing the highest classified data in the system to a user possessing the 
lowest clearance. 

Today, the military model of hierarchical data classification is one of the most 
widely used data ranking methods. Unclassified, sensitive unclassified, confidential, 
secret, and top secret are types of data classification used in this model. The military 
model gives an effective basis for access control of these data. The Information Security 
Program Regulation presents well-defined procedures dealing with differently classified 
data [Ref 50]. In terms of data integration in a data flow model (e g., the Bel-LaPadula 
model), however, the strong differentiation of data types in the military model does not 
promise the integration of those data, since any user who has a higher level of clearance 
than that ascribed to the objects can access and read those objects, but cannot produce 
any objects with a lower level of classification [Ref 35: p. 249]. Although higher levels 
of classified data are more reliable in general, the actual data processing work in this 
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model should be done with lower or, at most, the same level of classified data; thus, the 
trustedness of the result may be lower than expected. 

On the other hand, industry uses a different data control scheme. Their intellectual 
proprietary data are protected by laws authorizing their patents, copyrights, or trade 
secrets. Yet, there are other groups of data that are highly sensitive to routine business 
but inadequate for those protection laws (e g., financial data or competition sensitive 
data). When compared to the military classification model, most sensitive data used in 
industry can be categorized into a confidential data type which includes financial, 
proprietary, and mission-sensitive data. 

Wfiien data classification requirements are determined early in the acquisition 
phase, CALS data classification should be done with careful consideration of data 
protection vs. data integration. In other words, to provide maximum data utilization in 
weapon systems development, only the sensitive part of documents or engineering 
drawings may have a higher classification for secrecy, while the other parts retain a normal 
classification. 

The data classification rule should be specific enough to cover the inference 
problem, which drives sensitive data fi'om non-sensitive data resulting from on-line query 
functions provided by CITIS. Although those results of query function are not 
predictable, the security policy concerning data classification should control inference 
problems by either suppressing obviously sensitive information, or by denying the query 
service. 


2. Technical Data Rights 

As mentioned earlier, CITIS will provide government access to a contractor's 
database, which contains government-owned data specified in the Contract Data 
Requirement List (CDRL), Government Furnished information (GFI), and contractor's 
proprietary data related to weapon system development and support. According to 
CITIS, for intellectual proprietary data the government shall not, as a consequence of the 
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delivery of a data item, acquire ownership of the data item or any rights or license to use, 
copy, or disclose such a data item. The extent and nature of rights that the government 
may acquire to use, copy, or disclose data items shall be as expressly stated in the contract 
[Ref 18: p. 12], 

When dealing with intellectual property, however, there is an increased risk of 
misuse of proprietary and business-sensitive data in digital form. No DoD regulation 
currently exists to assess liability of third parties for copyright or patent infringement. 
Even with access limitations, proprietary markings, such as proprietary legends and 
restrictive distribution statements, may be inadvertently deleted [Ref 8: p. 7-37]. 

Thus, when the government fears disclosure of classified data handled by 
contractors and discontinuity of CITIS support due to the nonexistence of original 
contractors, the contractors fear the loss of their technical leading edge. The most 
prevailing belief in most government contracting activities is that the government buys too 
much technical data, and doesn't protect licensed data adequately [Ref 55: p. 14]. To 
achieve the shared data environment, CALS requires harmonized cooperation between the 
government and contractors. But if the government paid more money for unlimited rights 
to the technical data, and still the contractors were afraid of the loss of control over their 
proprietary data, then the benefits of CALS from a shared common database would be 
hard to achieve. Therefore, to envision a fully integrated CALS environment, a strong 
agreement on data rights and on the following regulations should be established between 
the government and contractors. 

3. Access Classification 

The two main users of CALS data are the government and contractors of a 
weapon system. In reality, the contractors are composed of various groups, such as the 
prime contractor, teamed contractors, subcontractors, suppliers, and vendors [Ref 18: p. 
5]. As all of these groups, including the government, have their own reasons for 
accessing CALS data, there should be a clear policy to distribute appropriate access 
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rights to those groups. To preserve the ownership of data, and to protect data abuse, 
these access rights should be carefully analyzed and granted. At present, the CALS 
Implementation Guide suggests five types of access rights: view only, comment/annotate, 
extract/process/transform, update/maintain, and archive [Ref 7: p. 87]. As those access 
rights are not mutually exclusive, a single user entry may have two or more rights. 

• View Only: The ability to examine a data file without the ability to change it. 
This includes viewing selected portions of one or several documents, as well as 
side-by-side comparisons of documents. 

• Comment/Anotate: The ability to evaluate and highlight for future reference or 
to make annotations, approvals, and comments without the ability to change the 
original file. 

• Extract/Process/Transform: The ability to extract and modify the format, 
composition, and structure of all or a portion of the data into another usable 
form without affecting the original content or format. 

• Update/Maintain: The ability to change data, either directly or through 
controlling software, in the active files on the host computer. 

• Archive: The placing of data into a repository to preserve it for future use. 

When using CITIS, the responsibility to control and maintain those access rights 
granted by an acquisition manager lies with the prime contractor who provides the 
electronically accessible database. Most of those access rights are related to the core 
functions of CITIS. Thus, any CITIS application provided by the contractor should 
support those access attributes when users access to data files or packages are stored 
primarily in the contractor's database. The decision to combine those access rights to 
each of the objects (e g.. Access Control List) or to build a separate matrix (e.g.. Access 
Control Matrix) depends on the database construction plan. As those objects would be 
divided into several different classifications, there should be a well-defined mandatory 
access control policy to support access rights only for users who have a relevant security 
clearance. 
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4. Access Control using Digital Signature 

When CALS is supported by a mature telecommunications infrastructure that 
allows on-line data transmission between the government sites and contractor sites, the 
users of CALS technical data must be able to exchange technical data for weapon systems. 
As data transmitted and processed by users will have various levels of sensitivity, there 
should be a trusted procedure to control access by users to only that level and category of 
information for which they are cleared and authorized (mandatory access control), and for 
which they possess a need-to-know (discretionary access control). 

The mandatory access control (MAC) dictates that a user's clearance level must 
meet certain criteria in order for the user to access an object with either read or wnte 
privileges. The MAC policy is enforced by the underlying operating system rated above 
B1 TCB. The discretionary access control (DAC) allows the creator of data or programs 
to specify the access other users may have to information under their control. The DAC 
policy is enforced by a set of rules for controlling and limiting access, based on identified 
individuals who have been determined to have a need-to-know for the information. It 
provides an additional finer granularity of control within the confines of MAC. 

To support these access control mechanisms, there should be a secure way to 
authenticate users who want to access to intellectual information. At present, enhanced 
access control mechanisms are provided by hardware devices (e.g., token and smart card). 
However, access control using those devices is restricted to a certain range of local 
authority; thus, it may not be used in CALS telecommunications architecture, which 
allows global user access across the boundary of a certain local security domain. The 
certified digital signature can act as a ubiquitous user identification across a local security 
domain. As mentioned earlier, the characteristics of digital signature, which can provide 
unforgeable, unalterable, nonreusable, and authentic messages are well fit for the strong 
authentication mechanism. The digital signature can serve for not only the access control, 
but also for the protection of intellectual property rights [Ref 56: p. EI-95]. When 
combined with enveloping methodology (the header portion of a data package/element) 
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already provided by MIL-STD-1840B, the digital signature can prevent unauthorized 
copying and use via digitally signed and certified property labels. 

However, prior to use of digital signature, a nationwide or even worldwide policy 
should be established for handling digital signature certificates that validate the identity of 
a user. 


5. International Data Exchange 

From nation to nation, international data exchange is complicated by differences in 
the treatment of intellectual data. Some nations do not recognize or protect intellectual 
property. Export licensing of technical data also creates a barrier to international 
cooperation using on-line data transfer, such as CITIS [Ref 8: p. 7-38]. 

At present, the Korean defense industry has the research and development capacity 
for advanced weapon systems, but they still largely depend on foreign technology for core 
technological components [Ref 57: p. 143]. As core technology contains highly sensitive 
or classified information, there should be a set of restriction policies to support on-line 
transmission of the information. DoD 5200.1-R, Information Security Program 
Regulation, presents such restrictions for information resulting from Foreign Military Sales 
(FMS) or Direct Commercial Sales, based on the assumption that this information would 
be shipped via off-line media [Ref 50: p.VIII-4], yet it doesn't specify any method 
allowing on-line interaction between the U.S. and foreign countries. 

As CALS is used to establish the paperless environment in the future, there should 
be a way to enable international cooperation in developing advanced weapon systems. 
Although encryption may help international data exchange, there should be a mutual 
agreement on the procedure and actual cryptosystems to convince each other that the 
information will be protected in a same or an equivalent manner in each country prior to 
the data interchange using encryption. 
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6. Weapon System Phase and IWSDB 

The construction of the IWSDB is the essential part of CALS implementation. 
IWSDB is a logical database that provides multi-weapon systems technical information, 
regardless of the physical location of actual data storage. It should contain all digital data 
required to support the life-cycle of a weapon system. As mentioned earlier, extensive 
network capabilities and flexible open system architecture are two basic requirements to 
accomplish this integrated database. 

The IWSDB should include military data depositories and contractor's databases. 
On-line data transmission among those databases will be supported by CITIS 
applications. To enable CITIS between users and information providers, however, 
interface parameters should be established (e.g., data elements. Global Data Dictionary 
and Directory (GDD/D), interface protocol). On the basis of security consideration, to 
control physically distributed databases is not an easy task. By its distributed 
characteristics, those databases may allow different classifications to the same level of 
data. As the strength of security is only as good as its weakest point, any weak access 
point to the databases may downgrade overall CALS security. Thus, the security policy 
governing database security should be able to control distributed, multi-level weapon 
systems databases. 

When on-line data transmission is enabled through CITIS, the main responsibility 
of information security lies with the contractors. The contractors should fulfill basic 
security requirements, such as risk analysis, regular backup, and access monitoring. 
However, it is not realistic to assign security responsibility to contractors for the entire 
life-cycle of a weapon system. Since most data transmission is anticipated to occur at the 
later phase of the life-cycle, during many users request technical information to maintain 
their weapon systems (e.g., technical manuals), the contractors should be able to control 
users' access requests on their databases. It is more realistic to construct regional CALS 
data repositories to support the later phase of weapon systems. They can be constructed 
in selected military CALS sites. As those data repositories are within the domain of 
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military information security, they will reduce certain amount of security risks. Also, 
they may act as backup systems for weapon systems information. The main advantage of 
constructing regional data repositories is the reduced requirement of on-line data 
transmission when regional sites are carefully selected by a actual data traffic analysis. 
To support this plan, the acquisition manager should carefully consider the future 
requirement of CALS data. 

7. Multi-Level Security and Security Risks 

CALS requires a secure architecture to control the effective utilization of 
technical information related to weapon systems life-cycle among military CALS sites 
and contractors. Most of the technical information used to support weapon systems is 
unclassified but sensitive data, but there also could be classified data. Thus, to provide 
adequate protection for both unclassified and classified data, and for other resources, 
CALS sites should be equipped with trusted systems, including computing systems and 
other networking components, which can handle differently classified data with DAC 
and MAC. Table 7 suggests that the components of CALS networks should be rated at 
least the B1 level of trusted computing systems to support MAC and DAC. Also, since 
not all users have a clearance or formal access approval for all technical data provided by 
IWSDB, the operating mode shall be a multi-level security mode. 

To meet the security requirement of the entire CALS communications 
infrastructure, there should be a way to accredit the networked systems at the B1 level, 
which are operated in multi-level security mode. On the basis of the interconnection 
rule, which is provided by TNI Part I, each device in the network must be separately 
accredited to operate in an approved security mode of operation, and with a specific 
accreditation range. However, even when the interconnection rule is followed, there may 
be other potential security problems that will require the implementation of additional 
constraints on the network, a global view of the network which is provided by TNI Part 
II. This global view of the network addresses two potential damages; propagation of 
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local risk and the cascading problem. The propagation of local risk is caused by 
weaknesses in other systems connected to the network, and the cascading problem exists 
when an attacker can take advantage of network connections to reduce the nominal 
system resistance against leaking information across a range of sensitivity levels [Ref 52: 
p. 39 - 48], 

The first problem can be prevented by logically or physically disconnecting the 
untrusted systems. For the CALS telecommunications network, those systems that are 
not related to provide or use technical data should be disconnected from the network, or 
else all other trusted systems should be equipped with cryptographic devices to logically 
isolate those untrusted communications. The cascading problem is usually caused by the 
installation of malicious software on the lowest resistance point in the network. To 
prevent this problem, there should be a security policy governing configuration 
management to prohibit installation of unscrutinized software, or use end-to-end 
encryption between trusted hosts. 

CALS technical data transmission supporting weapon systems development and 
maintenance may allow a common untrusted path between military CALS sites and 
contractors for the cost-effective means of a common data carrier. Also, other 
connections within military CALS sites and contractors may be allowed, even after 
CALS is implemented. Thus, the environment of CALS telecommunications suggests 
that the use of an encryption tool is a more favorable method than the discormection or 
isolation of other networks that are not related to CALS telecommunications. 

D. PROPOSED SECURE TELECOMMUNICATIONS ARCHITECTURE 

This section summarizes the analysis presented in the previous chapters to 
provide a secure telecommunications architecture. The main purpose of this section is to 
envision the openness of connecting various systems for data integrity, and to suggest 
security requirements for data protection. In general, any protection mechanism will 
cause a certain amount of overhead from integration. However, without adequate 
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protection, the integration will be easily ruined, and the true meaning of integration will 
not be accomplished. Thus, it is important to treat security requirements as part of the 
essential building blocks of the CALS telecommunications plan. 

1. Open System Architecture and Internetworking 

a. Open System Employment 

To make networks interoperable, there are two important points that 
should be considered prior to the actual plan; the network protocols and applications. The 
two major protocol suites that promise open system networking are OSI protocols and 
TCP/IP protocols. Considering the networking trends in the Korean government and 
industry, TCP/IP protocols are more widely accepted as providing the best 
interoperability to their heterogeneous computers. Continuous growth of the Internet 
gives a momentum toward further enhancement of TCP/IP protocols and other network 
applications using TCP/IP. For the CALS data communications, either TCP/IP 
applications, such as FTP, or the contractor-developed applications using TCP/IP 
protocols will be used. On the other hand, as OSI protocols are also gaining popularity 
with their X.400 message handling service and X.500 descriptive naming services 
(which are very important for secure message delivery and public key certificates), these 
two standards should be considered as parts of essential applications along with other 
TCP/IP applications. The application gateways bridging TCP/IP protocols and OSI 
protocols are already available in the present market place; thus, those gateways don't 
need additional development efforts. However, the two OSI applications still are not 
fully developed for actual usage, and there also are efforts to develop equivalent 
applications using TCP/IP protocols, so it will be more flexible to decide the gateway 
option in the mid-term phase of the CALS telecommunications plan. 
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b. Local Area Connectivity 


When LAN, used in the CALS telecommunications, is defined as a 
network connecting computing devices within a military CALS site or a contractor site, 
the connectivity of those devices can be achieved by various means of networking 
technologies. Actually, any LAN technology can be used with TCP/IP protocols without 
affecting the long-haul connectivity. At present, FDDI is one of the best choices for 
LAN, providing high-bandwidth capacity to the network applications. Not only for LAN, 
FDDI can also be used for a Metropolitan Area Network (MAN) with its ability to 
connect across tens of kilometers [Ref 58: p. 64]. Thus, if there were a specific location 
where both military CALS site and contractors (including subcontractors) were dispersed 
within a city, FDDI can act as both LAN and WAN, with more than 100 Mbps 
bandwidth. 

At present, even if already-employed LAN technologies are not FDDI, the 
capacity in these technologies is larger than the current WAN capacity. Therefore, the 
CALS cites that use other LAN technologies can continuously use their LAN connection, 
at least until the WAN capacity overcomes the capacity of their LAN. However, newly 
employed LAN should consider FDDI as the most adequate technology. 

There should be a consideration of wireless LAN technologies for the 
specific CALS sites that require mobile computing capability (e.g., naval shipyards). 
Electronic TMs are examples that require mobile computing for weapon systems 
maintenance. Currently available wireless LAN technologies are: infrared lightwave, 
spread spectrum, and microwave radio. Although wireless LAN technologies will be 
necessary for these maintenance purposes, the decision to select a specific LAN 
technology will be based on the characteristics of the specific CALS site. 
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c. Wide Area Connectivity 


For CALS data transmission, there should be a long-haul connectivity 
between military CALS sites and contractors. This can be provided by either newly 
employed, dedicated lines between them, or by common carriers used for other 
communication purposes. To construct a WAN for only CALS purpose is not a 
cost-effective method. Thus, for CALS communication, already installed, or planned 
future common carriers are more favorable. 

For communications between CALS sites, the DDN (KDDN) can be used. 
The KDDN was planned in 1992, and the first stage of KDDN will be completed by the 
end of 1995. At present, based on the X.25 frame relay, the backbone capacity of KDDN 
varies between 9.6 Kbps and 1.544 Mbps, whereas local branched lines only support 9.6 
Kbps. This may be enough for a small amount of data transmission, but, the same as for 
U.S. DDN, it cannot be a cost-effective media to handle on-line transmission of 
extremely large technical data transmission. However, as it is anticipated that the KDDN 
will have large bandwidth in its future stages, along with the overall development plan of 
the Korean Information Infrastructure (KII), CALS communications between the military 
sites should take into account the development phases of the KDDN. 

For communications between military sites and contractors, the present 
commercial Internet (e.g., KORNET) can be used with a bandwidth of T1 (1.544 Mbps). 
The T1 capacity may give a reasonable bandwidth for CALS data transmission, although 
the required bandwidth may vary, depending on the amount of communications between 
those sites. As the capacity of the commercial Internet will be increased along with the 
KII development plan, the future capacity of the commercial Internet will give sufficient 
bandwidth for CALS data transmission between military sites and contractors. 

At present, the Korean government places a high priority on the 
construction of a robust, information-sensitive, socio-economic infrastructure, the Korea 
Information Infrastructure (KII). The KII is divided into two categories: the New Korea 
Net-Government (NKN-G) for the government sector, and the New Korea Net-Public 
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(NKN-P) for public sector. [Ref 59] The KII will employ ATM for their WAN 
technology. Both the NKN-G and NKN-P have a three-phased plan to construct a 
high-bandwidth backbone, and to implement related services. The planned networking 
capacity of the KJI is shown in Table 9. As the KDDN will be part of the NKN-G (even 
though it is separately constructed for security purposes) while the commercial Internet is 
being integrated into the NKN-P, the telecommunications plan for CALS should follow 
the phased plan of the KII to achieve a cost-effective means of on-line data transmission. 

Table 9. Network Capacity of the KII 



NKN-G 

NKN-P 

Groundwork 

stage 

(1995-1997) 

• Backbone capacity 

- between major cities: 622-2.5 Gbps 

- between major cities and hub cities: 622 Mbps 

• Interconnection between LAN: above 45 Mbps 

• Backbone capacity: 

155-622 Mbps 

• Local subscriber loop: 

2 Mbps class 

Diffusion 

stage 

(1998-2002) 

• Backbone capacity 

- between major cities: above 2.5 Gbps 

- between major cities and hub cities: 622-2.5 Gbps 

• Interconnection between LAN: above 155 Mbps 

• Backbone capacity: 

2.5-10 Gbps 

• Local subscriber loop: 

45-155 Mbps 

Completion 

stage 

(2003-2015) 

♦ Backbone capacity 

- several tens of Gbps up to several Tbps 

• Backbone capacity: 100 Gbps 

• Local subscriber loop: 155 Mbps 


2. Security Plan for CALS Telecommunications 

Currently, the Korean military has security regulations for secure computing and 
communications. However, to control information systems security in a highly integrated 
environment, there should be more specific security domain standards and regulations. 
For the successful CALS implementation, there is an urgent necessity to set an overall 
security policy governing the security concerns about technical information used in the 
CALS environment. The domains of those security requirements are various. The 
overall security policy should cover computer security, information security, and 
communications security, as well as physical security of CALS sites. As part of this 












overall security policy, the security plan for CALS communications should include: 
secure computer systems acquisition and management, data and user classification, data 
protection mechanisms, rules for information transfer, and roles of security 
administrators. 


a. Systems Acquisition and Management 

For computer systems acquisition and management, there should be 
functional criteria for secure computing systems (including communicational devices) that 
will be used in the CALS environment. Most of the workstations used in Korea were 
imported from other countries without security considerations. For those systems, the 
policy must define add-on security devices and software. Also, the policy will help future 
acquisition decisions about computing systems and related networking devices. The 
policy should provide CALS sites with the procedural guidance required to maintain the 
operability of systems (e.g., risk analysis, regular backup, monitoring, and contingency 
plan), which is tailorable to match the specific working environment of the site. 

b. Data and User Classification 

The security policy should provide the criteria to classify technical 
information used in a weapon systems life-cycle. For technical data, the classifying criteria 
should reflect the integrity of information (i.e., minimum restrictions on technical data) to 
fully utilize technical information within a distributed environment. It will also define the 
security head portion of any digitized data element to visualize the security label of 
information. The security policy must provide the criteria required to set the clearance of 
non-governmental users, and related procedures to assign the clearance (e g., security 
training and briefing). For the integrated CALS environment, the relationship between 
users and technical data will be governed by access attributes (e g., access privileges, and 
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release authority for information transfer). Those attributes will be assigned to each data 
elements through database control mechanisms (e.g., ACL, ACM). 

c. Data Protection Mechanism 

The policy must define the actual methods to protect information from 
unauthorized use, wire tapping, and other security attacks. Most communication security 
can be provided by encryption. Link-encryption (which can be performed without the 
knowledge or participation of a user's process) can be primarily used, since the users of 
CALS data may not have the background to implement an appropriate encryption method. 
Later, end-to-end encryption, which requires the user's responsibility for performing 
encryption, should be employed to give the user a choice of when to use encryption and 
which encryption algorithm to use. In a highly integrated environment, it wiU be more 
proper to protect CALS data by differentiating the encryption mechanisms with the types 
of classifications. 

There should be two categories to specify the security mechanisms: 
mandatory and tailorable. Mandatory mechanisms should define the types of 
cryptographic devices and applications, secure key management, and required reports and 
documentation. Tailorable mechanisms should represent the site's unique situation, and 
provide the mechanisms for access control, auditing, database management, 
communication channel analysis, a security recovery plan, and other tailorable functions 
required to maintain information security at a site. 

d. Rules for Information Transfer 

The security policy should define the rules by which technical information 
is securely transferred from one site to another. It should be embedded within guidance 
standards such as MIL-STD-1840B and CITIS, or separately defined in an information 
handling guidance. The rules will define the procedures required to handle an element of 
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information, or a package of information within differently configured sites. To protect 
certain levels of classified information, the rules should define the way in which 
information is upgraded or downgraded to support the overall access control mechanism. 
Those rules will also specify procedures to classify results of on-line queries to prevent the 
inference problems that usually happen in a database security. 

e. Role of Security Administrator 

The security policy should define specific roles of security administrators 
who take the most responsibility related to site security. These roles should consist of 
regular duties and special requirements reflecting specific roles and the environment of a 
site. In an environment dealing with paper-based, classified information, there might be 
little cooperation between acquisition managers and security administrators. However, in 
a highly integrated environment, where information is transferred at light speed, there 
should be high-degree of cooperation between these two personnel, to provide 
information security without affecting weapon systems development and maintenance. 
Thus, the security administrators should be aware of overall acquisition procedures and 
data flows within a weapon system life-cycle, in addition to information security 
requirements. 

3. Secure CALS Telecommunications Architecture 

To establish an interoperable CALS environment, the CALS telecommunications 
implementation will reflect the time frames of national information infrastructure 
development plan. Also, the close relationship between telecommunications and network 
security suggests that the network security development plan will have the same time 
frames. The phases can be divided into three terms: the near-term, mid-term, and 
long-term phase 
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In the near-term phase, the current KDDN will be used to connect military CALS 
sites, while the commercial Internet will provide a communication channel between 
military sites and contractors. In the mid-term phase, the second phase of KDDN will 
provide a high band-width communications channel between military CALS sites, while 
the diffusion stage of NKN-P will provide the communications channel for military CALS 
sites and contractors. In the long-term phase, it is anticipated that CALS will have enough 
band-width for on-line data transmission; thus the telecommunications implementation 
plan will focus on the extension of the on-line CALS services. 

For telecommunications security, the near-term phase will focus on the 
establishment of security policy, and on the development of enhanced cryptographic 
devices. In the mid-term phase, connection-oriented security will be implemented via 
domestic commercial equipment. In the long-term phase, management of 
telecommunications security will be focused as a network security model to influence the 
overall military information infrastructure. 

a. Near-Term Phase 

For CALS telecommunications, current KDDN can be used as a 
coimection channel between military CALS sites. However, as the capacity of current 
KDDN is not enough for transmitting technical information, only limited data traflBc will 
be allowed. For the communication between contractors and military CALS sites, the 
commercial Internet will provide a communications chaimel, either as a direct connection 
or as a common carrier (e.g., VAN), depending on the availability of the service. The 
communications security will be provided by a link encryption device, which is currently 
used for KDDN security, and by an isolation policy, which denies any connection except 
the CALS-specific access requirements. 

In this phase, the effort to implement CALS telecommunications will be 
focused on four areas; (1) the digitization of technical data and bulk data delivery through 
the adaptation of MIL-STD-1840B, (2) data traffic analysis between data repository and 
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actual users, (3) construction of high band-width LANs, and (4) preparation of TCP/IP 
protocols-equipped computers and network devices. 

For communications security, there are many more requirements that 
should be done during the near-term phase. Those requirements are: (1) establishment of 
security policy and related regulations concerning computer security, information security, 
and telecommunications security, (2) provision of CALS-specific security policy 
governing the role of information security in weapon systems acquisition phases, in which 
information is shared with non-military organizations, (3) development of add-on security 
devices and applications providing additional security features to non-secure computing 
systems, (4) construction of security gateways to deny any connection requirements from 
unauthorized users, (5) configuration for a closed community within military CALS sites 
and contractors, (6) analysis of the strength of cryptographic algorithms that were not 
developed in Korea, and their availability in the international environment, and (7) 
developing enhanced cryptographic algorithms and security devices that minimize the 
security overhead against telecommunications performance. 

b. Mid-Term Phase 

In this phase, as a part of the second stage of the NKN-G project, the 
DISN is expected to support all required CALS telecommunications requirements within 
military CALS sites. In a public communications domain, the NKN-P project will also 
support the connection between military CALS sites and contractors. As on-line CALS 
data transmission will be realized in this phase, a secure CALS telecommunications 
implementation should focus on the on-line functionality of telecommunications and 
connection-oriented security service. 

For CALS telecommunications, the requirements are: (1) maintaining 
wide-area connectivity utilizing ATM technology, (2) development of CITIS applications, 
which will enable on-line data transfers from the contractor's data depository to military 
CALS users, (3) continuous development of networking applications using advanced 
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information technologies, and (4) simplifying the management of interfaces between the 
local and wide-area environment to maximize the integrity of information. 

On the other hand, the telecommunications security should provide 
adequate protection for the real-time data transmissions. To support on-line CALS 
telecommunications, connection-oriented security mechanisms should include: (1) 
developing public key encryption technology and key management technology, (2) 
simplifying security procedures required in the multi-level, integrated information 
environment through developing a portable device for access control, user authentication, 
and key exchange, (3) development of intelligent gateways to control real-time user 
queries while maintainin g original data classifications criteria (i.e., protection against 
inference attacks), (4) interaction with other security service mechanisms to achieve 
overall CALS security, and (5) provision for international data exchange to accelerate 
weapon systems development. 

c. Long-Term Phase 

The KII is expected to be completed in this phase. Through the 
nation-wide information infrastructure, CALS data can be easily transmitted and the use of 
CALS data can be optimized. In this phase, CALS telecommunications will focus the 
expansion of the interactive services directly connecting any technical information to its 
actual user through automated security procedures. However, highly integrated 
information systems are more vulnerable to security attacks than isolated systems. It may 
be very difficult to evolve from a paper-based information environment to a integrated, 
digitized information environment. But, it will be much more difficult to return to the old 
stage from an integrated environment. Since the dependency on automated information 
systems has been increasing, it may provide an easily identifiable target for any malicious 
attempt. This is one of the reasons why currently U.S. makes provisions for "Information 
Warfare." Thus, the goal of secure CALS telecommunications implementation in the 
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long-term phase should focus on the maintainability of the CALS telecommunications 
architecture. 

To support such a goal in this phase, the effort to implement CALS 
telecommunications should focus on: (1) continuous development/adaptation of 
telecommunications technologies, (2) migration from a closed community to an open 
community to optimize the information infrastructure, and (3) ensuring minimum 
redundancy on its information architecture. 

The telecommunications security in this phase deals with requirements such 
as: (1) development of secure telecommunications protocols, such as networking 
protocols and protection mechanisms using encryption, (2) Refinement of security 
management on CALS telecommunications with distributed networks management 
functions, and (3) provision of a multilevel secure network model to influence overall 
military information infrastructure. Table 10 summarizes the requirements suggested for 
the secure CALS telecommunications architecture. 
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Table 10. Phased Approach for Secure CALS Telecommunications Architecture 


Phase 

Telecommunications 

Requirements 

Security Requirements 

Near-term 

• Digitize technical data 

• Analyze data traffic requirements 

• Construct high band-width LANs 

• Use TCP/IP protocols for 
interoperability 

• Set security policy and related 
regulations 

• Provide CALS-specific security 
policy 

• Develop security devices and 
applications 

• Construct security gateways 

• Configure closed community 

• Analyze strength of cryptographic 
algorithms 

• Develop enhanced ciyptosystems 

Mid-term 

• Utilize ATM technology for 
WAN 

• Develop CITIS applications 

• Develop networking applications 

• Simplify interface management 

• Facilitate public key technology 

• Simplify security procedures 

• Develop intelligent gateways for 
databases 

• Interact with other security services 

Long-term 

• Develop/adapt new technology 

• Evolve to an open community 

• Ensure minimum redundancy 

• Develop secure telecommunications 
protocols 

• Refine security management on 

CALS telecommunications 

• Provide a multi-level secure network 
model 
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VI. CONCLUSION 


CALS is more than a collection of automated information systems. It is a strategy 
to increase the national potential which can employ rapidly evolving information 
technology. The benefits that could be achieved from CALS include not only efficient or 
cost-effective information management and control in a national defense environment, 
but also an advanced national competitive power in the highly competitive, information 
technology-based international market place. In the U.S., the term CALS is not limited 
to the defense industry. It is extended to a new concept, such as the Enterprise 
Integration Strategy, which can change all conventional data processing works to an 
equivalent or even an enhanced, digitized version. 

Although those benefits may not be achieved in a short period, the Korean 
government and defense industry should invest in CALS for the future. The MND must 
initiate a pilot project to modernize toward a cost-effective CALS solution for acquiring 
and managing digitized information by means of joint service systems. Also, the industry 
must enhance their information infrastructure, and increase their international 
competitiveness. 

To achieve streamlined interoperability, the efforts to implement CALS in Korea 
should start with the adaptation of CALS standards, a common bridge that enabling 
organizations to exchange and share information more efficiently. Streamlined 
information processing will provide the opportunity to do business in the most efficient 
way by removing any redundant and unnecessary steps. Emerging CALS standards and 
information technologies to enable streamlined business processes should be adapted 
early or developed by the Korean industry. 

To support this working environment, the telecommunications capability acts as 
one of the most significant part of CALS infrastructure. Without connectivity, any effort 
toward a highly integrated working environment cannot accomplish its goal. The most 
widely used telecommunications protocols should be selected, and continuously evolved 
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to enable a better opportunity to integrate a separated working environment. A 
telecommunications capacity should be achieved via the national effort to develop a 
nation-wide information infrastructure. The CALS initiative will demonstrate how the 
nation-wide infrastructure can be used to enhance cooperation between the government 
and industry, and contribute a large portion of return on the initial investment. 

At present, however, to provide appropriate means of protection for the 
confidentiality of CALS information is one of the key challenges. In a highly integrated 
working environment, the potential vulnerability dramatically increases while the 
importance of each data element is increasing. Any damage to the data used in the 
integrated working environment will cause much more cost for recovery than one in a 
isolated working environment. Even worse, the potential damage to CALS technical data 
may compromise national security. As any method to protect this information usually 
causes a certain amount of security overhead to the integrated CALS environment, the 
decision to select security mechanisms should be made based on the comparison between 
security and integrity, in terms of efficiency, effectiveness, and availability. 

"Perfect security" may not be possible. Rather, security mechanisms will reduce 
the degree of information systems vulnerability to an acceptable level. Among the 
various security mechanisms, the most effective protection method against network 
attacks is encryption. Currently developed public key algorithms provide a much more 
flexible way to ensure data authenticity and confidentiality. Along with a well-defined 
security policy and related regulations, public key algorithms can provide most of the 
security service needed for sensitive information. The development of publicly available 
cryptography will also contribute to the security of a national information infrastructure. 

In the CALS environment, the acquisition manager, other government users of 
technical data, and the contractors have a shared responsibility to provide an adequate 
level of protection in all CALS-related delivery and access modes. As the security is only 
as good as its weakest point, all of the security contributors should cooperate to 
accomplish overall CALS information security. 
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